Idea: tmx support

I think Tiled is a nice way to create levels for games.
There is a C librarythat is able to parse the tmx file format.
It has examples for its usage with allegro and sdl, maybe we should add an example with raylib?
This is their example folder.
I started doing this but I am not too much familiar with raylib yet, and thus its very hard for me. Maybe someone can help? :)

Or would including that lib with some nicer wrapper functions or writing own raylib tmx parser be more appropriate?
I think Tiled is quite popular, and is also heavily used from Love2d people. This could be a good step towards making raylib more popular again?

Hi @jubalh!
I love Tiled but I think tmx support is out of scope of raylib, it would be more proper for a raylib code example. I prefer to keep the library with basic generic functionality for any kind of game; tmx is very game-type centric.
Creating a raylib example for TMX library shouldn't be difficult but it requires some time...

Hi @raysan5 !

Creating a raylib example for TMX library shouldn't be difficult but it requires some time...

Do you think you can find some time for doing this? It would be awesome.
I also created an issue for it on the tmx c library.

Hey @jubalh!
It's on my list, really, but I'm a bit overloaded with several things in my daily work and I can't find the time to work in deep in most of the pending issues... just have some small time spots that don't give me enough concentration space to work on complex issues...
Could you setup a basic example with some .tmx map + required textures + expected result screenshot to start working with it? It would be easier for me to go straight to loading and drawing implementations.

I totally understand. And I definitely don't want to push :)
I think https://github.com/baylej/tmx/blob/master/examples/sdl/sdl.c is a very good thing to look it. Basically it shows how to use the tmx library to get the content out of the .tmx file. It then uses SDL to draw the content. https://github.com/baylej/tmx/blob/master/examples/allegro/allegro.c shows the same for allegro.
As I see it, you could just use one of those, and adapt the SDL calls to the raylib calls. allegro and sdl usage of tmx are very similar they just use their respective APIs to draw unto a canvas and get the canvas it seems.
In https://github.com/baylej/tmx/tree/master/examples/data he also has example .tmx files.
I just looked through my harddisk and realized that I still have my attempt of writing the raylib example. I committed it now and pushed it to: https://github.com/jubalh/tmx/tree/master/examples/raylib
raylib.c was about taking the sdl example and changing it to use raylib calls.
raylib2.c was starting with a base raylib project and adding the tmx calls.
I didn't get very far. Also for time reasons, but even more so because I don't know enough about raylib and drawing things on the screen in general.

Hi there,
I still think TMX support would be something worthwhile. Especially for people coming from love2d this would be a thing they would miss. It would attract more users of raylib I think. And one doesnt need to invent their own map format.

ok, let's give it another opportunity...

Raylib plays oggs. For me this is not much different and plans to do networking. For me this is not more out of scope.
It has to parse xml files and create structs for this which then can be displayed.
Love2D and others do it too.
I agree that adding an example to the tmx library would be an alternative.
But since raylib adds networking and so many non core game related things it could as well add a tmx module of itself. So that the syntax, usage and naming is closer to raylib than an external library like tmx.

@jubalh networking is a feature that many games today could require, independently of the game style, same as ogg playing... but TMX map support is a very specific requirement for a specific kind of game and for maps created with a specific tool (Tiled).
Supporting that format on raylib is not that trivial, requires lot of work and despite being a possible addition, it's definetely very low priority for me. As always, I'm open to collaboration and accept PR requests.
Also consider that all external libraries included in raylib to support specific file-formats  are single-file header-only.
@terrehbyte Creating a raylib example seems a good alternative.

Just linking to a TMX loading example.

Wow, supercool! Thanks!

Avoid example shows a TMX implementation for raylib. No plans to add it to the library. Closing the issue.


work-in-progress PR to show changes for type parameter support

The way the tests I added are written now is a little rough, but I hope it shows what the feature would look like in practice.

@JosephJNK great :-)
Maybe we should rename the .feature files with a number at the beginning. To better see during code review what is the foundation and what advanced features are allowed on top of that.

@JosephJNK The features seem great. I definitely agree to add this to Finitio!
My main concern is that the syntax for type instantiation, e.g. LinkedList(String) might clash with subtyping, e.g. LinkedList( list | list.length>0 ). I'm not sure it is a big problem, though, as it seems that a lookahead of 1 is enough to distinguish the two cases.
Second concern would be "how to implement it?", of course.

@JosephJNK very nice feature indeed!

@blambeau I was meaning to ask you about the choice of "()" for declaring type parameters. Depending on the language, parenthesis, square brackets or angle brackets would all be common. I think they should all parse unambiguously, since this declaration can only occur before an equals sign, so I can change it to whatever you find most aesthetically appealing.
As far as how to implement it... I'm still working that out. Hopefully I'll have an answer to that added to this PR by the end of next weekend.

I think they should all parse unambiguously, since this declaration can only occur before an equals sign

@JosephJNK not only before an equals sign, as type instantiation (vs. parametric declaration)  uses parentheses too in your proposal. I need to think about it.

@blambeau My thinking was that as instantiation, it would be separated from subtyping because there won't be a "|" inside the parenthesis, but I could see how this could get hairy.


doc: polishing

What's changed?

Added some inline code blocks, and which => that
What's your motivation?

To help out with the documentation
Anything in particular you'd like reviewers to focus on?

Anyone you would like to review specifically?

Have you considered any alternatives or workarounds?

Any additional context

Checklist

[x] I've added unit tests to cover both positive and negative cases
[x] I've added the license header to any new files through ./gradlew licenseFormat
[x] I've used the IntelliJ IDEA auto-formatter on affected files
[x] I've updated the documentation (if applicable)

Thanks @SimonVerhoeven !


Mongoose: Remove hook not triggered when removing

The remove hook will not be triggered while call Schema#findAndRemove.
This is a known circumstance by mongoose https://github.com/learnboost/mongoose/issues/1241 and marked as not a bug.
The easiest way would be to call find in routes.js and then remove in the callback.
See also http://mongoosejs.com/docs/api.html#model_Model.findOneAndRemove

Sorry for not merging this. I think this is now handled correctly.
I need a test to check events working properly.


Multiple ViroARTrackingTargets in react viro

I have faced with this problem. I want create multi image detection application. So I am downloading images from url and alocate them to arrays. So I want create multiple ViroARTrackingTargets. How to do it? Anyone help!

Hey @030131550542, please refer to our documentation when determining which component to use for building an AR experience, where we have multiple guides that may help you out.
For example, there is a guide that deals with image markers. You can also refer to our code samples repo here for more examples.
If you are looking for developers to write code for you, you may be able to find developers who have previously developed with Viro in our Slack channel.
Also, please use github issues for reporting bugs on the platform, not for requesting written code for your business application, thanks!


removing  set_defaults

It's not used  in MLJModels or MLJ so I think it's safe to just remove it.
Though it would be breaking so for a minor release.

Codecov Report

Merging #120 into dev will increase coverage by 0.51%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##              dev     #120      +/-   ##
==========================================
+ Coverage   69.85%   70.37%   +0.51%
==========================================
  Files          21       21
  Lines        1088     1080       -8
==========================================
  Hits          760      760
+ Misses        328      320       -8

Impacted Files
Coverage Δ

src/utilities.jl
20% <ø> (+11.66%)
:arrow_up:

src/data.jl
86.31% <0%> (+0.89%)
:arrow_up:

Continue to review full report at Codecov.

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

@set_defaults is still used in MLJ to defined new model  types in  the @from_network macro. So this will have to wait, sorry.

I'm closing as this is now old, there are now merge conflicts, and, given its low priority, is unlikely to see the light of day


Bosh silently ignores unknown fields

If you specify a deployment job field that doesn't exist, such as jobs.*.disk_type instead of jobs.*.persistent_disk_type, Bosh will not fail or even warn you of a non-existent field being used. In our use case this has led to Bosh not deploying as expected (it picked up the underlying ephemeral disk defined in the vm_type).
It seems there should be some kind of schema of known fields (that are not under any extensible namespace, such as properties) to provide warnings of potential typos. This will help prevent Bosh (potentially silently) failing to do what is expected.

+1000. we are definitely planning to get to this.

Closing this one as https://github.com/cloudfoundry/bosh/issues/1568 seems to be a duplicate with a bit more context


Cannot build network echo_server for nucleo_f767zi

Describe the bug
Following dts errors are shown when trying to compile echo_server sample app for nucleo_f767zi
west build -d build -b nucleo_f767zi samples/net/sockets/echo_server
-- west build: generating a build system
Including boilerplate (Zephyr base (cached)): ./zephyr/cmake/app/boilerplate.cmake
-- Application: ./zephyr/samples/net/sockets/echo_server
-- Zephyr version: 2.4.99 (./zephyr)
-- Found west (found suitable version "0.8.0", minimum required is "0.7.1")
-- Board: nucleo_f767zi
-- Cache files will be written to: ~/.cache/zephyr
-- Found toolchain: zephyr (/opt/zephyr-sdk)
-- Found dtc: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found BOARD.dts: ./zephyr/boards/arm/nucleo_f767zi/nucleo_f767zi.dts
nucleo_f767zi.dts.pre.tmp:329.8-335.6: ERROR (phandle_references): /soc/timers@40010000/pwm: Reference to non-existent node or label "tim1_ch3_pe13"

  also defined at nucleo_f767zi.dts.pre.tmp:1937.12-1940.4
nucleo_f767zi.dts.pre.tmp:580.22-588.5: ERROR (phandle_references): /soc/adc@40012000: Reference to non-existent node or label "adc1_in0_pa0"

  also defined at nucleo_f767zi.dts.pre.tmp:1962.7-1965.3
nucleo_f767zi.dts.pre.tmp:689.26-701.5: ERROR (phandle_references): /soc/ethernet@40028000: Reference to non-existent node or label "eth_mdc_pc1"

  also defined at nucleo_f767zi.dts.pre.tmp:1969.6-1980.3
nucleo_f767zi.dts.pre.tmp:689.26-701.5: ERROR (phandle_references): /soc/ethernet@40028000: Reference to non-existent node or label "eth_rxd0_pc4"

  also defined at nucleo_f767zi.dts.pre.tmp:1969.6-1980.3
nucleo_f767zi.dts.pre.tmp:689.26-701.5: ERROR (phandle_references): /soc/ethernet@40028000: Reference to non-existent node or label "eth_rxd1_pc5"

  also defined at nucleo_f767zi.dts.pre.tmp:1969.6-1980.3
nucleo_f767zi.dts.pre.tmp:689.26-701.5: ERROR (phandle_references): /soc/ethernet@40028000: Reference to non-existent node or label "eth_ref_clk_pa1"

  also defined at nucleo_f767zi.dts.pre.tmp:1969.6-1980.3
nucleo_f767zi.dts.pre.tmp:689.26-701.5: ERROR (phandle_references): /soc/ethernet@40028000: Reference to non-existent node or label "eth_mdio_pa2"

  also defined at nucleo_f767zi.dts.pre.tmp:1969.6-1980.3
nucleo_f767zi.dts.pre.tmp:689.26-701.5: ERROR (phandle_references): /soc/ethernet@40028000: Reference to non-existent node or label "eth_crs_dv_pa7"

  also defined at nucleo_f767zi.dts.pre.tmp:1969.6-1980.3
nucleo_f767zi.dts.pre.tmp:689.26-701.5: ERROR (phandle_references): /soc/ethernet@40028000: Reference to non-existent node or label "eth_tx_en_pg11"

  also defined at nucleo_f767zi.dts.pre.tmp:1969.6-1980.3
nucleo_f767zi.dts.pre.tmp:689.26-701.5: ERROR (phandle_references): /soc/ethernet@40028000: Reference to non-existent node or label "eth_txd0_pg13"

  also defined at nucleo_f767zi.dts.pre.tmp:1969.6-1980.3
nucleo_f767zi.dts.pre.tmp:689.26-701.5: ERROR (phandle_references): /soc/ethernet@40028000: Reference to non-existent node or label "eth_txd1_pb13"

  also defined at nucleo_f767zi.dts.pre.tmp:1969.6-1980.3
ERROR: Input tree has errors, aborting (use -f to force output)
CMake Error at ./zephyr/cmake/dts.cmake:209 (message):
  command failed with return code: 2
Call Stack (most recent call first):
  ./zephyr/cmake/app/boilerplate.cmake:506 (include)
  ./zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
  ./zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
  CMakeLists.txt:5 (find_package)

-- Configuring incomplete, errors occurred!
FATAL ERROR: command exited with status 1: ~/.local/bin/cmake -DWEST_PYTHON=/usr/bin/python3 -B./zephyr/build -S./zephyr/samples/net/sockets/echo_server -GNinja

To Reproduce
west build -d build -b nucleo_f767zi samples/net/sockets/echo_server
Environment (please complete the following information):

OS: Fedora 33
SDK 0.11.3
Commit SHA: 7a3f9c4e391f75558c74cbebcd503f16c6ed047c

@jukkar can you try west udpate ?

Indeed that was the case. I forgot to update the HAL. Sorry for the noise.


FYI Journald receiver docs need updating to show support for operators

Opened issue on collector repo, xposting for visibility.
https://github.com/signalfx/splunk-otel-collector/issues/2570#issue-1588273687

Work is complete. Closing.


add support for apache-composer-python

this won't be happening any time soon. future citizens: PRs gladly accepted, but it isn't a priority for the foreseeable future.


Node Disruptions should have separate Budgets

Description
What problem are you trying to solve?
We would like to have a more controlled approach to node disruptions.
Our workloads have use cases where we would love to have different schedule windows for different disruption methods.
Drift disruptions requires a maintenance windows as this is critical if the user wants to modify a instance type with around 50 instances in the node pool , such node disruptions needs to be actively monitored during a maintenance window, to make sure that the workloads are up and healthy post the drift.
Node Expiration disruptions is a little less critical as different nodes expire at different times the impact may be less but still would like to rotate expired nodes during a different maintenance window.
Finally consolidation disruption with a policy of whenEmpty is the least critical and the node can be removed by karpenter to save cost any time and do not require a maintenance window.
How important is this feature to you?

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

This would be a great feature for AKS as well since we drive upgrade through IsDrifted(), it would be good to define a budget for example only for drift to control the times when we perform cluster upgrade.
cc: @charliedmcb

/assign Bryce-Soghigian

@prad9192 I would love to get your feedback on the discussions going on in the design :)

Hi, I arrived at this issue from https://github.com/kubernetes-sigs/karpenter/issues/672, which describes a similar need that I have.
I'm looking to have more control over how and why Karpenter evicts pods.  The main problem that I'm trying to solve is to prevent Karpenter from consolidating certain workloads, but doing so in such a way that node expiration is not prevented.  If a given node belongs to a NodePool that has expireAfter set, I would like that node to be drained / deleted once the TTL is met, despite the fact that there may be pods on that node that do not want to be consolidated.
Today, I can partially achieve this with the karpenter.sh/do-not-disrupt annotation, but this also prevents nodes from expiring.  My current workaround is using a CronJob that forcefully deletes nodes that are alive past their TTL that karpenter cannot remove due to this limitation.

Design is approved and merged. I am working on cleaning up the implementation and then we should be golden.


Add in rate limit for HTTP requests

This originates from the discussion in #454. Part of what we want do with rate limits is allow for rate limiting API endpoints. To do so, the simplest mechanism would be implementing some ASGI middleware for rate limiting API requests. There are already existing middleware that for rate limiting api requests that we could use, though they may not be entirely ideal:

slowapi - Uses the limits api, but tools for setting limits on endpoints is fairly limited
asgi-ratelimit - Better tooling for setting limits on endponts, but uses its own api for the limits themselves, making it difficult to interoperate with other rate limit tools.

It may be better to look into implementing our own middleware to merge the parts we like about both sets of tools.

Here's a blueprint for specifying API rate limits.
API Rate Limit Specification Format
This document is for how rate limits shall be specified for API endpoints. These rate limits are global, shared across all users, and are meant to be used to address technical constraints. Rate limits will be provided as a list[dict], which each enclosed dict containing match, limit, and method attributes.
The value of the limit attribute determines the rate limit for the matched URLs.
The value of the method attribute is a list of HTTP methods to rate limit for.
The value of the match attribute will be used to construct a regular expression which will attempt to match against a URL. Any subgroups of the regex will be used for providing finer rate limit controls, e.g. rate limiting per object ID.
The list of rate limits will be evaluated in sequential order. If a requested URL matches the regular expression and HTTP method, it will then generate a hit on that limit. If the rate limit is exceeded, the server will return code 503, service unavailable. If the rate limit is not exceeded, the request is allowed to go through, without evaluating any more possible matches.
api_rate_limits = [
	{
		"method": ["GET"],
		"match": "`^/switches/(?P<switch_id>\w*)/$`",
		"limit": "amount/time unit"
	},
	...
]


fix: looks like a typo - network interfaces with attached elb wont lo…

fix: looks like a typo - network interfaces with attached elb wont load into neo4j because they are tuple instead of string

Current version of the CLA: 1.0
Username
petersutter5
CLA Version
Signed and current (1.0)

extra commits due to trying to pass the CLA check by adding my username and email to my git config.


Feature/circleci cache node modules

The CI/CD pipeline from feature/zdt-test brach doesn't have caching functionality, despite it being supported. The caching support provided by CircleCI is limited as of 09/18:

No support for save_cache key path globbing.
No support for multiple checksums as key names
No support for checksum on directories
Cannot export {{ .ENVIRONMENT.variableName }} using an eval expression such as $(ls)

This PR is a temporary workaround to enable caching. It will require the user to run the md5sum command listed in CONTRIBUTING.md anytime a new module is installed or modified assuming checksums of the package-lock.json
Quick caching tests show:

With cache:  ~7 mins
Without cache: ~12 mins

I am going to add this to the icebox until circle ci updates how this works. Currently we have a lot of processes to follow when deploying and I don't want to add another just yet.

Closing this in favour of #603.
Using yarn with a single hoisted node_modules folder makes circleci caching way easier 💯


Broken Link Found in Documentation

In Avoid Side Effects (part 2) the outbound link to facebook.github.io/immutable-js/ is broken

can you assign it to me? ill start updating the link

i have updated the link with a new link. you can close this issue

I have a made a pr fixing this issue.

#401 look up to this


Quantum Break renders incorrectly - black rectangles

Quantum Break renders incorrectly in some situations. Some shadows/lighting are incorrect, sometimes in the shape of black rectangles:

Software information
Quantum Break: https://pcgamingwiki.com/wiki/Quantum_Break
Problem occurs on all settings: from low to ultra.
System information

GPU: GeForce GTX 970
Driver: 396.51.0
Wine version: wine-3.13 (Staging)
DXVK version: 0.65

Apitrace file(s)
Without DXVK game crashes when save finisehs loading (menu works). I tried:
WINEDLLOVERRIDES="d3d11,dxgi=b" wine /home/konrad/Pobrane/apitrace-msvc/x64/bin/apitrace.exe trace --api dxgi -v QuantumBreak.exe
But no trace was generated and game crashed.
With these DLLs game crashed on start, but trace file was generated (useless I guess).
Log files
QuantumBreak_d3d11.log
QuantumBreak_dxgi.log

Can't do anything without an apitrace. Also I'm pretty sure that the game did render correctly at some point, if you can't trace it, please check if it works with older drivers and/or dxvk.

First missions are OK or graphic error are less visible. It was the first time where it is so clearly visible, but I found problems in other areas too.
I tested it on Windows on the latest drivers (398.82). With DXVK there is exactly the same issue (performance is also similar). It still can be a driver bug, Nvidia uses the same common code on all platforms.
Anyway, I was able to create apitrace on Windows:
https://www.dropbox.com/sh/ziy9sku1qn8c8kn/AACFTdVDah0SSzgYaPld2WbDa?dl=0
There are two traces:

QuantumBreak1.trace (1,7 GB) - game crashed after few seconds, but trace should be fine.
QuantumBreak2.trace (1,9 GB) - scene rendered for few seconds, then I quit the game

I also uploaded save from that moment, if you wish to test using it you need to put it in:
~/.wine/drive_c/users/$USER/Local Settings/Application Data/QuantumBreak

Thanks for uploading trace files. Unfortunately I cannot debug the problem because replaying the traces causes a GPU hang.

I finally managed to grab a renderdoc capture of a frame. There are small lighting artifacts, but it's not nearly as bad on my RX 480 as it is on your screenshot. The problem might be related though.
Unfortunately it also appears that the buffer that seems to contain faulty data is only updated once while loading the game/level, which makes this exceptionally hard to debug.

Is there anything I can help (except patch :))? I can send you the Steam key if it helps (no obligations).

This can be closed, issue was fixed with version 0.72. I've checked 0.71 (still rendering issues), 0.72 and all newer are fine. Thanks!


[Doc] Update the download page with 1.5.1 release

Description
(Brief description on what this PR is about)
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at https://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

@aaronmarkham @ThomasDelteil @szha Please help to review and merge. Thanks!

@TaoLv thanks for taking care of the release.
You also need to update this line: https://github.com/apache/incubator-mxnet/blob/master/docs/static_site/src/_includes/get_started/get_started.html#L27
and this table:
https://github.com/apache/incubator-mxnet/blob/master/docs/static_site/src/_includes/get_started/pip_snippet.md#L6
@aaronmarkham how is this table created? Do we have a master somewhere?

@ThomasDelteil, I have changed the versions and the pip package table. Could you please take a look again?
@aaronmarkham, Not sure I understand the question. The artifacts of these download links have already been archived here: https://apache.org/dist/incubator/mxnet/1.5.1/.

Is it good to merge now? @ThomasDelteil @aaronmarkham


Detect and deal with stale manifests.

Currently, we don’t check the nextUpdate field of a manifest. We need to add a check for that which may put the manifest into a "stale" state. See section 6.4 of RFC 6486. How to deal with this is "local policy," so we need a way to set and use this local policy.

Tests for staleness of manifests and CRLs have been added in #19. Routinator now prints warnings if these are stale.


Auto merge auto-update-weights-for-dev-dbf13a812089ba6b59f3b87318cb4874541e7ab5 to dev

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (3a1bf6e) 72.20% compared to head (344c00f) 13.68%.

Additional details and impacted files
@@             Coverage Diff             @@
##              dev    #1468       +/-   ##
===========================================
- Coverage   72.20%   13.68%   -58.53%
===========================================
  Files         111       31       -80
  Lines       13123     1001    -12122
  Branches      128      128
===========================================
- Hits         9476      137     -9339
+ Misses       3637      864     -2773
+ Partials       10        0       -10

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Remove BalanceTitleView if it's not used anymore #1848

Closes #1848

@vladyslav-iosdev looks good, can you help remove BalanceTokenViewModel too? Seems not used.

BalanceTokenViewModel

@hboon But it used in
case .ERC20Token(let token, _, _):
            let viewModel = BalanceTokenViewModel(token: token)
            let amount = viewModel.amountShort
            //Note that if we want to display the token name directly from token.name, we have to be careful that DAI token's name has trailing \0
            headerViewModel.title = "\(amount) \(token.titleInPluralForm(withAssetDefinitionStore: assetDefinitionStore))"
            let etherToken = TokensDataStore.etherToken(forServer: session.server)
            let ticker = tokensDataStore.coinTicker(for: etherToken)
            headerViewModel.ticker = ticker
            headerViewModel.currencyAmount = session.balanceCoordinator.viewModel.currencyAmount
            headerViewModel.currencyAmountWithoutSymbol = session.balanceCoordinator.viewModel.currencyAmountWithoutSymbol
            if let viewModel = self.viewModel {
                configure(viewModel: viewModel)
            }
        case .ERC875Token, .ERC875TokenOrder, .ERC721Token, .ERC721ForTicketToken, .dapp:
            break
        }

looks good, can you help remove BalanceTokenViewModel too? Seems not used.

done

@vladyslav-iosdev can you help rebase master and make it a single commit? Sorry, got caught up and didn't get to this earlier.

ou help rebase master and make it a single commit? Sorry, got caught up and didn't get to this earlier.

Done


The order of the arguments in the usage example in the docs is wrong

There's a mistake in the README documentation. Here (https://github.com/jeanbmar/s3-sync-client#sync-the-local-file-system-with-a-remote-s3-bucket) it says:

Sync the local file system with a remote S3 bucket
await sync('s3://mybucket', '/path/to/some/local', { del: true });

However it should be the other way around, since the first argument is the source and the second is target. The heading states that it should sync a local folder into the remote S3 bucket, but it's doing exactly the opposite.
This can lead to a data loss locally, in fact, I didn't verify that this method is working as document, so a bunch of local files got deleted. Fortunately, I was testing it on a random directory and not something important.

It is not really a mistake since it's intended to mean "synchronize a target with a source".
But I understand it can be misleading. I'll change it to Sync from S3 bucket to local file system.


investigate excessive cache clearing

DJ does WAY too much cache clearing, so much so that it might negate the advantage of caching in the first place. Starting with the issues @pleary raised in #449, look into caches that we should probably drop (e.g. cached components), and try to find the sources of those duplicate clearing jobs.

I'm hopeful that change to LifeList.refresh_listed_taxon (the final form is in 15a3d02a199facc321622f66a85ef86a25cff88c after a couple commits) will remove a double cache clear for deleted life list entries. It was previously saving the record then checking if it should be deleted, each step was clearing caches. I changed it to directly call the before_save filter we were depending on, and moved the destroy check above the save to ensure the record is saved only once.
Another fix was the removal of the ListedTaxonSweeper in 30be68c4a341fef7a76adc9793e2641da8695f1a. ListedTaxon has an after_commit :expire_caches which will clear the cache after any save or deletion. The sweeper was calling expire_listed_taxon(listed_taxon), which is just listed_taxon.expire_caches. That means the caches were getting cleared, then the record was saved and caches were cleared again.


Support Dataset and DatasetBuilder

This pr support the Dataset and DatasetBuilder for wormhole migration.

Codecov Report
Base: 0.00% // Head: 73.05% // Increases project coverage by +73.05% :tada:

Coverage data is based on head (400662b) compared to base (d8bfa7a).
Patch coverage: 86.88% of modified lines in pull request are covered.

Additional details and impacted files
@@              Coverage Diff              @@
##             master    #2323       +/-   ##
=============================================
+ Coverage          0   73.05%   +73.05%
- Complexity        0    10526    +10526
=============================================
  Files             0      759      +759
  Lines             0    58329    +58329
  Branches          0     7156     +7156
=============================================
+ Hits              0    42612    +42612
- Misses            0    13365    +13365
- Partials          0     2352     +2352

Impacted Files
Coverage Δ

.../java/com/github/ambry/account/DatasetBuilder.java
83.78% <83.78%> (ø)

...rc/main/java/com/github/ambry/account/Dataset.java
91.66% <91.66%> (ø)

...b/ambry/frontend/AmbryIdSigningServiceFactory.java
100.00% <0.00%> (ø)

.../com/github/ambry/cloud/CloudStorageCompactor.java
73.03% <0.00%> (ø)

...ithub/ambry/messageformat/BlobPropertiesSerDe.java
89.09% <0.00%> (ø)

...a/com/github/ambry/clustermap/ClusterMapUtils.java
92.82% <0.00%> (ø)

.../java/com/github/ambry/frontend/FrontendUtils.java
82.14% <0.00%> (ø)

...ustermap/PropertyStoreToDataNodeConfigAdapter.java
90.40% <0.00%> (ø)

...ain/java/com/github/ambry/protocol/PutRequest.java
74.12% <0.00%> (ø)

...m/github/ambry/clustermap/AmbryServerDataNode.java
85.29% <0.00%> (ø)

... and 749 more

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

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


Exporting the gradient to MontePython

Hi! I'm working on modifying MontePython with an HMC/NUTS solver, which requires getting the gradient of loglkl. I would like to use candl for the CMB data, but I don't see a function that would directly give me the gradient vector. Is there a simple way to add this as a function in the likelihood classes (basically a log_like_grad(self, params))?

Hello and thanks for your interest in using candl! Having access to gradient based samplers in MontePython would be amazing.
The simplest way to get gradients would be to do jax.jacrev(like_func) where like_func is a function that moves from parameters to logL values, i.e. first calls a differentiable theory code (e.g. CosmoPower emulators) and then hands the result off to candl in one step. I would warn against trying to do this piece-wise (theory and likelihood independently), as the input of cand likelihoods is relatively large (unbinned CMB spectra) and thus this calculation is computationally expensive.

Thank you for the answer! I am currently using a modified version of CLASS with improved non-linear contributions for my theory calculations for several extensions of LCDM. So if I understand the CosmoPower method correctly, the most effective way is to train my own emulators for each cosmological model using CLASS and then use these new emulators with candl, correct?

That does sound like the faster way, but I think for general accessibility being able to fall back to running directly with a Boltzmann solver is important. So will I still be able to use JAX on the result of get_params_to_logl_func if I use it with get_CLASS_pars_to_theory_specs_func rather than get_CosmoPower_pars_to_theory_specs_func?

Yes that's the idea re CosmoPower. Though note that a suite of pre-trained models are already available (eg here and here). While they may not match your needs exactly it can be a helpful starting point to build the pipeline and make the necessary modifications to MontePython before investing the time & CPU hours into training your own models.
As for the second question, no. CLASS is not compatible with autodiff and hence you will not be able to use JAX to get gradients from it. Currently, no differentiable Boltzmann solvers that calculate CMB Cls are available within python/JAX so emulators are the only solution for now I'm afraid.

Hello again! I've settled on using CosmoPower and am now working on the general calls for the gradients. I need a function in candl_mp/__init__.py that translates (self, cosmo, data) into the result of jax.value_and_grad(self.candl_like.log_like(pars_for_like)). Am I correctly understanding that I can just implement a loglkl_and_grad function that is identical to loglkl except for the last two lines which are changed to
loglkl_vg = value_and_grad(self.candl_like.log_like)
return loglkl_vg(pars_for_like)

Hello, I think that would work though I would propose to to define a new function in candl_mp that simply calls jax.value_and_grad(self.loglkl) in order to keep things clean. The JAX function should allow for the specification of which arguments to differentiate wrt to, to avoid doing so for MontePython quantities that are not of interest. If this should turn out to be too complicated, what you have proposed is perfectly fine too.
One last thing to note is that jitting as in your snippet above is ineffective as one would incur the first-time-use penalty at every evaluation as the function is being re-jitted. Instead, adding a decorator before the function definition is the way to go.

Ah, I see! I'm new to JAX, so still getting my bearings.
Thanks for the advice!


 It looks like you may be using an old version of VS Code, the latest stable release is 1.84.2. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

The problem is that I am having Snap as my default store, when I search vs
code, I see more than 5 apps with same official logo, I can't know which is
official.
So maybe I should be helped with the package id on snap or apt, all on
Zorin OS. I saw code codium vscode vscodium and so on....
Thank you.
On Thu, Nov 16, 2023 at 7:36 AM VSCode Triage Bot @.***>
wrote:

Thanks for creating this issue! It looks like you may be using an old
version of VS Code, the latest stable release is 1.84.2. Please try
upgrading to the latest version and checking whether this issue remains.
Happy Coding!
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/198388#issuecomment-1813929662,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFAG36B4JONLSFZMPGXA5SLYEW7BDAVCNFSM6AAAAAA7NWBCLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJTHEZDSNRWGI
.
You are receiving this because you authored the thread.Message ID:
@.***>

Maybe this helps https://code.visualstudio.com/docs/setup/linux#_snap


[Feature] Show app usage stats to developers and admins

Summary
We should show usage stats to developers and admins of an org so that they know what apps are being used and how much.
We can either let the user integrate GA or we print the stats

Closing this issue as it being now tracked under https://github.com/appsmithorg/appsmith/issues/21245


Forseti Release 2.23.3

Release fix for model creation.

Forseti release and website PRs are pending:

https://github.com/forseti-security/forseti-security/pull/3789
https://github.com/forseti-security/forseti-security/pull/3790

Forseti release has been created, ready to complete the release once these 2 PRs get merged:

https://github.com/forseti-security/forseti-security/pull/3791
https://github.com/forseti-security/terraform-google-forseti/pull/600


Calibnet sync check GH Action

Issue summary

Implement a check that verifies on a push (both PR and merge to main) that Forest can sync to calibnet. This check should be done on the buildjet machines.

[ ] Download the latest calibnet snapshot (use forest chain fetch),
[ ] Run forest, importing the snapshot,
[ ] Wait for sync. It'll be nice to do a health check as well.

Other information and links

The check will most likely need to be disabled when calibnet goes NV17, as we lack proper migrations.

Extra bonus points if you do it in the code coverage action and include the results in the coverage report.

No bonus points - the code coverage action with calibnet check would take a long time (at least 40 minutes on release mode, but then we'd get a lot of false negatives because of optimized code).


Add USDC and CRBRUS to main

Should we still use 'axl' prefix on main info site? Should we still use the USDC token logo with the little axl icon over it?


[UPDATE ALGORITHM] Find 3 consecutive element in array

Description:
I would like to add an alogorithm which give 3 consecutive lement
Checklist:

[X} Contributor in GSSoC-ext
[X] Want to work on it

Affected Algorithm:
Mention which algorithm you want to update and the specific directory where you want to change.
Additional Information:
Any extra details or suggestions related to the update.

Do not create new issues until your previous one complete, wait until you’re assigned.


Implement _check and passed all tests!

Delete me and write your Pull Request message here!

Thank you @danthareja !!


Introduce raw data callbacks

These callbacks can be used when developing transparent HTTP traffic analysis and filtering.
The main goal of it is to handle transmitted data as-is, but having ability to distinguish data between headers, bodies and different requests.

Thank you for submitting this! May I ask you to write a short example in C to demonstrate how this API could be used?

I just figured out that we need to change position of callbacks in http_parser_settings structure to keep it backward-compatible. I'll update PR and then will do short example.

Short example on how it can be used:
std::string hdr;

static int headers_raw(http_parser*parser, const char *at, size_t length)
{
	hdr.append(at, length)
}

static int headers_complete(http_parser*parser)
{
	do_anything_when_headers_received();
	send(fd, hdr.c_str(), hdr.size());
	hdr.clear();
}

static int body_raw(http_parser*parser, const char *at, size_t length)
{
	send(fd, at, length);
}

But when developing complex processing, we need keep in mind, that on_header_raw() callback can be received before on_message_begin. It's easy to reproduce - just send alone newline symbol  before sending request. It happening because of non-caching nature of HTTP parser.

The numerous style errors alone make this pull request unsuitable for inclusion in its current shape.  As to the functionality, I have no strong opinion on whether it's a good addition.
Something to keep in mind is that http_parser is more strict in what it accepts than most browsers.  If you're going to use it for MitM-style analysis or filtering, you may have a hard time.

@bnoordhuis, I don't  insist, but these additions extend the limits of applicability of the parser.
Writing transparent proxy with support of keep-alive and pipelining very difficult (if possible at all) without raw data callbacks. Using raw callbacks it becomes quite easy.

I'll let @indutny make the call on whether or not to accept this pull request.

Writing transparent proxy with support of keep-alive and pipelining very difficult (if possible at all) without raw data callbacks.

Is that really true?  It's my experience that transparent proxies still frequently need to rewrite parts of the request and the response.

@bnoordhuis, there are different tasks for proxying. Main goal of raw callbacks is to keep control of request/response sequence without need of reassembling stream before forwarding.

@RandoMan70 I don't really object to this change, but on other hand try to avoid touching that code. It is very sensitive code path, which may ruin the performance of the method because of high register pressure.
What do you think about doing this under some build-time define? Clearly this feature is not something that the most of the users will use, so it will make more sense to do it this way.

Just store that here: https://github.com/OISF/libhtp/pull/123 exactly the same, but in libhtp!

@RandoMan70 can you write me a message<EMAIL_ADDRESS>

@indutny it's possible, sure. But don't sure that it can significantly affect performance - checks executed mosly once per call and per request/response switch.

Not in v2.x since it changes the ABI.  Maybe in 3.0 if and when that is released.
(It could be put behind a build-time flag but that's mighty inconvenient for some downstream users.  Distros already have a hard enough time with the strict and non-strict builds.)


Windows: Spanish setting only applies on the loading screen

From @vanessa-chang at https://github.com/endlessm/kolibri-explore-plugin/issues/861
In the latest Windows app: <IP_ADDRESS>
OS language settings

The loading screen is in Spanish but the following screens are still in English.

I have opened a PR that is basically a port of (part of) https://github.com/endlessm/kolibri-installer-android/pull/188 . Please note that existing installations would still be in English. Further work is needed for fixing that (add a "Windows plugin" like we have in Android, add a migration script).

Works fine in 7.10.427 - QA pass.


CHEBI:146764 add synonyms

CHEBI:146764 is known as

Lacto-N-neooctaose
LNnO

Ref.: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9235823/ (Table II, compound IX)

Now added. Thanks


New retirement enhancements.

Consolidated retirement enhancement code.
https://trello.com/c/vdIdXEdT
The current VM and Service retirement functionality relies heavily on internal processing which significantly limits its usefulness. Moving that functionality into the state machine provides the flexibility to better control the actions during retirement. The goal is to provide a solid out of the box retirement state machine that can be easily modified and customized. It has the added benefit of making the retirement and provisioning state machines very similar which provides a more consistent tool for controlling the entire VM and Service lifecycle.
One new feature is the addition of the retirement_state attribute which enables us to detect when the retirement process starts and finishes, and when an error occurs. This will help address the long standing issue of multiple conflicting retirement state machines.
VM retire_now - Existing behavior:

set retire flag
raise vm_retired event*
raise audit event
power off VM * note - There is a built-in policy for the vm_retired event that causes the vm to be powered off. If vm retired == true and power_state == on, raise the action of vm_stop
*Event calls into Automate (Requires policy assignment)
/System/Event/vm_retired
/[cloud/infra]/VM//Retirement/Statemachines/vmretirement/default

         1. Checkpoweredoff
         2. ….
         n. Remove VM

VM retire_now - Enhancement:

raise request_vm_retire event*
*Event calls into Automate (With no policy assignment)
/System/Event/request_vm_retired
/[cloud/infra]/VM//Retirement/Statemachines/vmretirement/default

        1. Start_Retirement - set retirement state to 'retiring’ NEW
        2. Power off vm NEW
        3. Check powered off
        4. ….
        n-1. Finish_retirement NEW
                 a. set retired flag
                 b. set retirement state to ‘retired’
                 c. raise vm_retired event
                 d. raise audit event
        n. Remove VM
        * note - Except for the Start_Retirement step, any retirement state machine step that ends in MIQ_ABORT will set the retirement_state to ‘error’

Service Retirement
Service retire_now - Existing behavior:

set retire flag
raise service_retired_event*
raise audit event
*Event calls into Automate (With no policy assignment)
/System/Event/service_retired
/Service/Lifecycle/Retirement
/Statemachine

      1. Retire service vms
      2. Check service retirement
      3. Mark service as retired
      4. Remove Service

Service retire_now - Enhancement:

raise request_service_retire event*
*Event calls into Automate (With no policy assignment)
/System/Event/request_service_retired
/Service/Lifecycle/Retirement

Automate method GetRetirementEntrypoint gets the service retirement entry point for call into state machine

        1. Start_Retirement - sets retirement state to 'retiring’ NEW
        2. Power off service? NEW
        3. Retire service - (calls into retire_now for each service resource)
        4. Check service retirement (make sure all service VMs are retired)
        5. Finish_retirement NEW
                 a. set retired flag
                 b. set retirement state to ‘retired’
                 c. raise service_retired event
                 d. raise audit event
        6. Remove Service
        * note - Except for the Start_Retirement step, any retirement state machine step that ends in MIQ_ABORT will set the retirement_state to ‘error’

Upgrade path:
Additional changes will be necessary for existing customers.

Change VMRetirement schema for new states
Add StartRetirement, FinishRetirement methods
Add /System/Event/request_vm_retire instance

@gmcculloug Please review.

@tinaafitz
Are the 2 instances Default and Retire_Service in /ManageIQ/Service/Retirement/StateMachines the same? if they are the same do we need only 1?


pipe doesn't work when there is a redirect

I'm trying to download google profile picture using superagent in node. When you request a url like this: "https://profiles.google.com/s2/photos/profile/GOOGLE_ID?access_token=ACCESS_TOKEN", google does redirect with the following message on body:

    <TITLE>Moved Temporarily</TITLE>

Moved Temporarily

    The document has moved here.

I got this message on the file I'm trying to write to.
This is my downloadFromUrl function:
    service.downloadFromUrl = function(url, cb) {
      var filename = uuid.v4().replace(/-/g, '');

      var stream = fs.createWriteStream('/tmp/' + filename);

      var req = request.get(url);

      req.on('end', function() {
        // check if file is valid and move to the correct folder
        cb(null, filename);
      });
      req.on('error', cb);

      req.pipe(stream);
    };

This is still an issue, can this be reopened?


Instantiate generic classes using expression tree, instead of new keyword

When T is a generic class, new T() is slow. In fact, it is just syntactic sugar and the actual code that is emitted to IL is Activator.CreateInstance<T>();, which uses reflection. A much faster way is to use lambda expression trees. There are many discussions on the web that describe this, e.g. http://stackoverflow.com/questions/6069661/does-system-activator-createinstancet-have-performance-issues-big-enough-to-di
I admit that it doesn't make a big difference in our test suite, but in a scenario where the user will create many thousands of the same object, it will make a difference. I have a test app that demonstrates the impact.

Sample program to illustrate different instantiate methods.

   public class TestClass
   {
   }

   public static class New<T> where T : new()
   {
      public static readonly Func<T> Instance = Expression.Lambda<Func<T>>(Expression.New(typeof(T))).Compile();
   }

   class Program
   {

      static void Main(string[] args)
      {
         const int IterationCount = 100000000;

         // warmup
         Test1();
         Test2();
         Test3();
         Test4<TestClass>();
         Test5<TestClass>();
         Test6<TestClass>();
         Test7<TestClass>();

         // profile Activator.CreateInstance<T>()
         Stopwatch sw = Stopwatch.StartNew();
         for (int index = 0; index < IterationCount; index++)
            Test1();
         sw.Stop();
         Console.WriteLine("Test1 - Activator.CreateInstance<T>(): {0}", sw.ElapsedMilliseconds);

         // profile new T()
         sw.Restart();
         for (int index = 0; index < IterationCount; index++)
            Test2();
         sw.Stop();
         Console.WriteLine("Test2 - new T() {0}", sw.ElapsedMilliseconds);

         // profile Delegate
         sw.Restart();
         for (int index = 0; index < IterationCount; index++)
            Test3();
         sw.Stop();
         Console.WriteLine("Test3 - Delegate {0}", sw.ElapsedMilliseconds);

         // profile generic new()
         sw.Restart();
         for (int index = 0; index < IterationCount; index++)
		 	Test4<TestClass>();
         sw.Stop();
         Console.WriteLine("Test4 - Generic new() {0}", sw.ElapsedMilliseconds);

         // generic Activator without bindings
         sw.Restart();
         for (int index = 0; index < IterationCount; index++)
			 Test5<TestClass>();
         sw.Stop();
         Console.WriteLine("Test5 - Generic activator {0}", sw.ElapsedMilliseconds);

         // profile Activator with bindings
         sw.Restart();
         for (int index = 0; index < IterationCount; index++)
            Test6<TestClass>();
         sw.Stop();
         Console.WriteLine("Test6 - Generic activator with bindings {0}", sw.ElapsedMilliseconds);

         sw.Restart();
         for (int index = 0; index < IterationCount; index++)
            Test7<TestClass>();
         sw.Stop();
         Console.WriteLine("Test7 - Generic with expression tree {0}", sw.ElapsedMilliseconds);

         // profile Baseline
         sw.Restart();
         for (int index = 0; index < IterationCount; index++)
            TestBaseline();
         sw.Stop();
         Console.WriteLine("Baseline {0}", sw.ElapsedMilliseconds);
         //Console.ReadKey(false);
      }

      public static void Test1()
      {
         var obj = Activator.CreateInstance<TestClass>();
         GC.KeepAlive(obj);
      }

      public static void Test2()
      {
         var obj = new TestClass();
         GC.KeepAlive(obj);
      }

      static Func<TestClass> Create = delegate
      {
         return new TestClass();
      };

      public static void Test3()
      {
         var obj = Create();
         GC.KeepAlive(obj);
      }

      public static void Test4<T>() where T : new()
      {
         var obj = new T();
         GC.KeepAlive(obj);
      }

      public static void Test5<T>()
      {
         var obj = ((T)Activator.CreateInstance(typeof(T)));
         GC.KeepAlive(obj);
      }

      private const BindingFlags anyAccess = BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic;

      public static void Test6<T>()
      {
         var obj = ((T)Activator.CreateInstance(typeof(T), anyAccess, null, null, null));
         GC.KeepAlive(obj);
      }

      public static void Test7<T>()
         where T : new()
      {
         var obj = New<T>.Instance();
         GC.KeepAlive(obj);
      }

      static TestClass x = new TestClass();
      public static void TestBaseline()
      {
         GC.KeepAlive(x);
      }
   }

Interesting , but , as someone commented,  In 90% of the case it's not an issue and having a new() constraint and calling new T() is much more readable.

Check that sample program and look at the difference it makes if you instantiate many objects. I'll do more tests to see if there are cases where it would speed up a QLNet project much.
I don't think the New<T>.Instance() syntax is much less readable though.

public static readonly Func<T> Instance = Expression.Lambda<Func<T>>(Expression.New(typeof(T))).Compile();
yup is easy :)

That's a once-off and is encapsulated in a helper class. You don't need to remember that.

First: I have only started looking into using this library so I am not proficient with naming conventions and so on, but here is some feedback.

God initiative +1
A good post on the same topic can be found on
https://blogs.msdn.microsoft.com/seteplia/2017/02/01/dissecting-the-new-constraint-in-c-a-perfect-example-of-a-leaky-abstraction/ the FastActivator.Create() seems promising and have somewhat better performance. As long as the internal API is in place it can be changed later on.
Naming

Method
Having a method/func named "Instance" sound a lot like something implementing a singleton pattern and not at all like a method allocating a new object. Create or New would be much better names in my opinion.
Class
Assuming that the method name changes something like

...Factory
...Activator (FastActivator as in the mentioned blog post does not sound so bad)

Visibility
Does it make sense to have this public to promote it as a feature for end users or should it be an implementation detail of the library and kept internal / private.

@Daniel-Svensson Valid points, but we've kind of put this on hold. The changes haven't really affected the run time of the unit tests, so I'm unsure whether the additional complexity is warranted. Do you have a counter-example where this change would make a real-world difference in performance?

Thx @Daniel-Svensson ,
now that codebase is on vs 2015, reading the great post of Sergey Teplyakov this become more urgent , because now it use Activator.CreateInstance() ( aka reflection ) and this is no good .


fix: use macos-12 instead of macos-latest in CI

What I did
The following issue seems to block python3.8-3.9 for macos arm: https://github.com/actions/setup-python/issues/808
NOTE: Anticipating things may still fail because of gacts/install-geth action
How I did it

How to verify it

Checklist

[ ] All changes are completed
[ ] New test cases have been added
[ ] Documentation has been updated

this user suggests getting rid of the setup-python action, in favor of manually installing python and pip (though i'd suggest uv pip). it seems to work for macos-13 as well. https://github.com/actions/setup-python/issues/696#issuecomment-1994554432

actions/setup-python#696 (comment)

We would have to separate mac-os from ubuntu more if we went this route. We have test.yml able to run on both, with the OS being in a matrix.

this user suggests getting rid of the setup-python action, in favor of manually installing python and pip (though i'd suggest uv pip). it seems to work for macos-13 as well. actions/setup-python#696 (comment)

because of the refactor required and my optimism 808 will be resolved, I want to stick to having macos in the matrix and using setup-pyhon... but will wait until for more thoughts before merging this.

you could get rid of setup-python entirely with a step like this (not saying this is the way to go, just an option, maybe if the action keeps giving you problems):
      - name: Install dependencies
        run: |
          if [ "$RUNNER_OS" == "Linux" ]; then
            apt update
            apt install -y python${{ matrix.python-version }}
          elif [ "$RUNNER_OS" == "macOS" ]; then
            brew update
            brew install python@${{ matrix.python-version }}
          fi

run: |
if [ "$RUNNER_OS" == "Linux" ]; then
apt update
apt install -y python${{ matrix.python-version }}
elif [ "$RUNNER_OS" == "macOS" ]; then
brew update
brew install python@${{ matrix.python-version }}
fi

eventually would also add windows here.

it feels like we are re-inventing wha setup-python is supposed to do... setup-python should be fixed, that seems like fixing it in the right spot.


Unfortunately no go but different errors.

Unfortunately no go but different errors after installing v1.0.1
Log entry 1:
This error originated from a custom integration.
Logger: custom_components.electrolux_status
Source: custom_components/electrolux_status/init.py:104
Integration: Electrolux Care Integration V2 (documentation, issues)
First occurred: 14:07:34 (1 occurrences)
Last logged: 14:07:34
'NoneType' object is not iterable
Traceback (most recent call last):
File "/config/custom_components/electrolux_status/init.py", line 104, in setup_entities
for appliance_json in appliances_list:
TypeError: 'NoneType' object is not iterable
=====
Log record 2
Logger: homeassistant.config_entries
Source: config_entries.py:406
First occurred: 14:07:34 (1 occurrences)
Last logged: 14:07:34
Error setting up entry<EMAIL_ADDRESS>for electrolux_status
Traceback (most recent call last):
File "/config/custom_components/electrolux_status/init.py", line 104, in setup_entities
for appliance_json in appliances_list:
TypeError: 'NoneType' object is not iterable
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 406, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/electrolux_status/init.py", line 58, in async_setup_entry
await coordinator.setup_entities()
File "/config/custom_components/electrolux_status/init.py", line 138, in setup_entities
raise UpdateFailed() from exception
homeassistant.helpers.update_coordinator.UpdateFailed
Originally posted by @slingshot74 in https://github.com/albaintor/homeassistant_electrolux_status/discussions/6#discussioncomment-8360578

V1.0.1 gives
File "/Users/daveprosee/Documents/python/core/config/custom_components/electrolux_status/select.py", line 60, in current_option
label = list(self.options_list.keys())[list(self.options_list.values()).index(value)]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: 'ON' is not in list
works on HA git clone with python 3.11 (with above error), but nog on current HA docker distribution with 3.11.

I had the same problem after i updated HA(os) tot 2024.1.6. Rolled back HA tot 2024.1.5 and the integration works again. Maybe this helps

I had the same problem after i updated HA(os) tot 2024.1.6. Rolled back HA tot 2024.1.5 and the integration works again. Maybe this helps

The only thing changed between those versions that might be related is: https://github.com/home-assistant/core/pull/109025

@bruin14 let us know if it keeps working on 2024.1.5

Core 2024.1.5
Supervisor 2023.12.1
Operating System 11.4
Frontend 20240104.0
I am running above version in a synology VM. I have a dryer and washer, both are detected correctly and work. So the basic of the integration works. The logs shows some erros. If you want me to make an issues of the errors then let me know.
For the rest, i see some entities that give back raw data I think. Not really sure what I should mention about that.
Anyway, big thks for the development !

It should be fixed now with the last version v1.0.2 or above


bump Rust

@bors r+

:pushpin: Commit ad1f0f6e65bbcdec4bba9a130105f86b56782ef7 has been approved by RalfJung

:hourglass: Testing commit ad1f0f6e65bbcdec4bba9a130105f86b56782ef7 with merge 0de35a0b913c72252bd56614a2de56f3891cf649...

:broken_heart: Test failed - status-appveyor

@bors r+

:pushpin: Commit 4d1a49fd6cb02273ed756bc719bc83c84b23b508 has been approved by RalfJung

:hourglass: Testing commit 4d1a49fd6cb02273ed756bc719bc83c84b23b508 with merge 7d9f29dad8cef80d2860a273106aff79fe538c8e...

:broken_heart: Test failed - status-appveyor

@bors r+

:pushpin: Commit db0d03229c54e3dead1cd8afde62e1ba9b1707bc has been approved by RalfJung

:hourglass: Testing commit db0d03229c54e3dead1cd8afde62e1ba9b1707bc with merge e05639a22596999e758fd0f598db23091e2c9837...

:sunny: Test successful - checks-travis, status-appveyor
Approved by: RalfJung
Pushing e05639a22596999e758fd0f598db23091e2c9837 to master...


NullReferenceException while trying to execute sample code

Whenever I try to execute the sample code:
var cam = Camera.Create(Capability.HandTracking);
cam.LeftHand.Visible += (s,a) => Console.WriteLine("Hi left hand!");
cam.RightHand.Closed += (s,a) => Console.WriteLine("Hand Closed");
cam.RightHand.Moved += (s,a) => {
Console.WriteLine("-> x:{0} y:{1}", a.Position.Image.X, a.Position.Image.Y);
};
cam.Start();
The software gets immediately stuck at the first line, saying "System.NullReferenceException: 'Object reference not set to an instance of an object.'"
Is there anything I missed?

Hi James,
This repo is for the Intel RealSense Camera, with the RealSense SDK version 10.
This is quite old, to be honest, I don't even think that they sell that camera anymore.
Are you using exactly this?

Well, those names are kind of confusing to me.
I have an Intel RealSense D435 Camera, which should be supported (?) and the most recent RealSense SDK v2.
I suppose they changed nomenclature at some point since I can't see how version 10 can be older than current v2.
Anyway, if SharpSenses devices are not supported anymore, I will try some other alternatives.
Thank you very much for your time!

Any time!
I will add a big line alerting people about it, thanks for reaching out.
Cheers.


ddev auth ssh fails: invalid mount config for type "bind": bind source path does not exist

Running ddev auth ssh results in error.
Here is the output:
docker: Error response from daemon: invalid mount config for type "bind": bind s ource path does not exist: /c/Users/[user]/.ssh. See 'docker run --help'. Docker command 'docker [run -it --rm --volumes-from=ddev-ssh-agent --user=1000 - -mount=type=bind,src=//c/Users/[user]/.ssh,dst=/home/[user]/.ssh drud/ddev -ssh-agent:v1.13.0-built ssh-add]' failed: exit status 125
In the docker "user-friendly" message the path is correct but in the command it has an extra slash. Running the command without this extra slash works fine.
The command has the same output in Powershell and Git Bash.
To Re-produce it just run ddev auth ssh in one of your projects.
Versions:
DDEV-Local version: v1.14.0-rc1
ddev-ssh-agent: drud/ddev-ssh-agent:v1.13.0
docker: 19.03.8
docker type: Docker Desktop For Windows
docker-compose: 1.25.0-rc4
os: windows 10

Could you please update to current ddev (v1.14.2) ?
Docker Desktop for Windows had a regression where it stopped accepting the "//", but they seem to have fixed that. What version of Docker Desktop for Windows are you using? Current is <IP_ADDRESS>
As a result of that regression, ddev's code was changed in recent alpha releases to lose the "//" as well (which was really helpful). But I think updating to current edge ddev release would also fix this, https://github.com/drud/ddev/releases/tag/v1.15-alpha4

I confirm that ddev auth ssh works fine with Docker Desktop for Windows <IP_ADDRESS> and ddev v1.4.2

I am running Docker Desktop for Windows ( <IP_ADDRESS> ).
Upgrading to ddev version 1.4.2 fixed the problem.
Thank you!

Glad it's working for you!


grab hostname from os.Hostname() instead of env

on my debian lenny os.Getenv("HOSTNAME") is empty and os.Hostname() should be more portable.

this looks like a nice small cleanup

Sorry to be so late at getting back at this. I'll take a look.

cherry-picked. you'll want to update your master branch.


Update VTKjs export

Update the VTK.js export functionality to catch up with https://github.com/pyvista/pyvista/pull/4569

I updated the GC test fixture to match the latest improvements in PyVista and looks like it's now causing failures here

@banesullivan I got a comment at some point about GC -- can you open a PR that updates the GC stuff here that shows the failures, then I can work to fix them at some point?

(Even if it doesn't cause failures, keeping the conftest.py changes in sync is worthwhile!)


Crash when analyzing process inside a docker container

# host system
System Version: macOS 10.15.4
❯ docker --version
Docker version 19.03.8, build afacb8b

# start a docker container
docker run -it  --privileged python:3.8 bash

# system info
root@12cafc138b77:/# cat /etc/*release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

root@12cafc138b77:/# gdb -v
GNU gdb (Debian 8.2.1-2+b3) 8.2.1

# install pre-requisites
apt install python3-dbg
pip3 install memory-analyzer
echo 0 > /proc/sys/kernel/yama/ptrace_scope

# start a simple python process
python3 -m http.server

# try to analyze
root@12cafc138b77:/# memory_analyzer run --debug 414  -e /usr/bin/python3
Analyzing pid 414
Setting up GDB for pid 414
0x00007f6c9b2717e4 in ?? ()
+set directories /usr/local/lib/python3.8/site-packages/memory_analyzer/
+py sys.path.append("/usr/local/lib/python3.8/site-packages/memory_analyzer/")
++file_command /tmp/tmpontmmnkq/rendered_template-414.py.out

Program received signal SIGSEGV, Segmentation fault.
PyGILState_Ensure () at ../Python/pystate.c:1049
Python Exception <class 'gdb.error'> The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(PyGILState_Ensure) will be abandoned.
When the function is done executing, GDB will silently stop.:
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/memory_analyzer//gdb_commands.py", line 47, in <module>
    TEMPLATES_PATH=TEMPLATES_PATH, pid=pid
gdb.error: Error occurred in Python command: The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(PyGILState_Ensure) will be abandoned.
When the function is done executing, GDB will silently stop.
[Inferior 1 (process 414) detached]
Gathering data...
ERROR: Analysis for 414 returned no data!  Try rerunning with --debug
ERROR: No results to report

Can you verify the versions match up?  I think python3-dbg and /usr/bin/python are 3.7 from debian, while /usr/local/bin/python (and /usr/local/bin/pip3) are from 3.8 and probably already has symbols.
I tried your commands (with the addition of apt-get update; apt-get install gdb first) and if you omit the -e /usr/bin/python3 it has reasonable output.

Thanks, that works nicely, I tried in a fresh container, and I dont need to install python3-dbg actually. memory_analyzer works without it, and also does not require the -e flag.


Broken/incorrect links on www.tangowithdjango.com

I found two issues with the book website. Here is how to reproduce them:

Go to the book website at https://www.tangowithdjango.com/
Scroll down to the section titled "Contact & Code"
Issue #1: If you click on the "Book Repository" block, you will get taken to a GitHub 404 page (i.e. Page Not Found) at https://github.com/tangowithcode/tango_with_django_4/issues/
Issue #2: If you click on the "Code & Tests Repository" block, you will get taken to https://github.com/tangowithcode/tango_with_django_4_code/issues/ but I think that was supposed to link to https://github.com/tangowithcode/tango_with_django_4_code (i.e. the whole repository, not its issues)

Thanks Troy!
Much appreciated.
On Wed, Aug 2, 2023 at 11:00 PM Troy McConaghy @.***>
wrote:

I found two issues with the book website. Here is how to reproduce them:

Go to the book website at https://www.tangowithdjango.com/
Scroll down to the section titled "Contact & Code"
Issue #1
https://github.com/tangowithcode/tango_with_django_4_code/issues/1:
If you click on the "Book Repository" block, you will get taken to a GitHub
404 page (i.e. Page Not Found) at
https://github.com/tangowithcode/tango_with_django_4/issues/
Issue #2: If you click on the "Code & Tests Repository" block, you
will get taken to
https://github.com/tangowithcode/tango_with_django_4_code/issues/ but
I think that was supposed to link to
https://github.com/tangowithcode/tango_with_django_4_code (i.e. the
whole repository, not its issues)

—
Reply to this email directly, view it on GitHub
https://github.com/tangowithcode/tango_with_django_4_code/issues/1, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOTMB35ZCCKTXPI5BSQFULXTLEZPANCNFSM6AAAAAA3B4FQKI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Release 0.25.0

It's time for our scheduled release.
Before we release this, #2865 is missing documentation from its "How we teach it" that needs to be merged before releasing. Once that is in, we are good to go.
We also need release notes for #2865. I think those release notes should address the 1/0 question and direct the user to an overview of what was added and where in the tutorial to go and learn more.
The only breaking change is from #2707.

Need release notes for:
@mfelsche

https://github.com/ponylang/ponyc/pull/2865
https://github.com/ponylang/ponyc/pull/2888
@Theodus
https://github.com/ponylang/ponyc/pull/2894
@dipinhora
https://github.com/ponylang/ponyc/pull/2889
@slfritchie
https://github.com/ponylang/ponyc/pull/2852

Waiting on release notes for
#2582 from @slfritchie and #2894 from @Theodus.

My plan is to bless b28ca7cee586ddb41c0303d1c5f2213d507f32f2 in the morning.

Waiting on release notes for
#2582 from @slfritchie

Release packaging scripts got broken. Waiting on https://github.com/ponylang/ponyc/pull/2902 to pass CI and be merged before proceeding. Thank @dipinhora for fixing.

release underway after a minor hiccup where i needed to resolve a merge conflict on the release branch.

Homebrew PR opened:
https://github.com/Homebrew/homebrew-core/pull/32958

@stefantalpalaru @kamilchm release underway

There are problems with the debian and ubuntu releases

Gentoo package updated.

Thanks @stefantalpalaru!

Everything is up and running again

Appimage is in bintray

Windows release is in bintray

Fedora COPR is done

0.25.0 is available via Dockerhub

@plietar Hey Paul, Playground didn't update to 0.25.0, its still at 0.24.4 for some reason.

Release notes PR opened: https://github.com/ponylang/ponylang-website/pull/347

Homebrew released

All done. Thanks folks!


documentation: Add example for various popular public registries

Which issue does this PR fix:
No issue, only documentation to give examples for most popular public registries.
What does this PR do / Why do we need it:
If an issue # is not available please add repro steps and logs showing the issue:
Testing done on this change:
At least one image has been pulled from each registry.
Automation added to e2e:
N/A
Will this break upgrades or downgrades?
No
Does this PR introduce any user-facing change?:
No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

can you also update this one: https://github.com/project-zot/zot/blob/main/test/blackbox/sync_docker.bats ?
There's a prefix filtering on all registries because we want to make sure that all registries are hit/used in the tests while syncing.

With regards to the commit message, we have some checks:

Please start the first line with 'docs', not 'doc'. I may look like the same, but the job is configured to use https://www.conventionalcommits.org/en/v1.0.0/
Please use git commit -s -S for signing

can you also update this one please: https://github.com/project-zot/zot/blob/main/test/blackbox/sync_docker.bats ? if not, I'll do it after merging it.
There's a prefix filtering on all registries because we want to make sure that all registries are hit/used in the tests while syncing.

I'd do that gladly but I'm not sure to understand what you want ?

@Poulpatine git commit --amend -s -S, both the Signed-off-by and signing with the GPG Key.

@Poulpatine git commit --amend -s -S, both the Signed-off-by and signing with the GPG Key.

Sure, let me fix that mismatch between my GPG key and my commit email and.

{"level":"error","config":"examples/config-popular-registries.json","time":"2023-06-23T16:03:48Z","message":"Config file is invalid"}
panic: config: invalid config
^ zot has a "verify" subcmd which can be used to validate the config file like so.
zot verify config-file
Also, your commits need to be signed with a "Signoff" in commit message.

hi @Poulpatine, please rebase locally. The merge commit messages are not compliant with the standard I mentioned above, so the check is failing.

hi @Poulpatine, please rebase locally. The merge commit messages are not compliant with the standard I mentioned above, so the check is failing.

Hi @andaaron ,
Ok, done.
Thanks.

hi @Poulpatine, please rebase locally. The merge commit messages are not compliant with the standard I mentioned above, so the check is failing.

Hi @andaaron ,
Ok, done.
Thanks.

Sure, no problem. Please also upload your new public signing key to your GH profile, so the commit shows as verified.

@Poulpatine thank you for your contribution, again!


Document that 'localhost' is necessary in ALLOWED_HOSTS

It's needed for the tornado server. Otherwise, you get errors like
2015-12-20 09:33:55,124 ERROR    Internal Server Error: /api/v1/events
Traceback (most recent call last):
File "/home/zulip/deployments/2015-12-20-13-44-47/zerver/management/commands/runtornado.py", line 209, in get_response
response = middleware_method(request)
File "/usr/lib/python2.7/dist-packages/django/middleware/common.py", line 62, in process_request
host = request.get_host()
File "/usr/lib/python2.7/dist-packages/django/http/request.py", line 101, in get_host
raise DisallowedHost(msg)
DisallowedHost: Invalid HTTP_HOST header: 'localhost:9993'. You may need to add u'localhost' to ALLOWED_HOSTS.

Automated message from Dropbox CLA bot
@rwbarton, it looks like you've already signed the Dropbox CLA. Thanks!

See for example https://github.com/zulip/zulip/issues/96#issuecomment-144787950.

Merged, thanks @rwbarton !  One small note -- we've been using a "." at the end of summary lines in commit messages.


Spy on stubbed calls

I'd like to suggest a feature for Stubber where you can spy on the calls that were made. I would find this useful in my tests for verifying that my code under test is invoking the API with expected arguments and data.

Seems reasonable. Something like a stubber.calls similar to mock


added support to detect change in groups of remote config as well

added support to detect changes in groups.
Fixed Issue #11

@amanBhawsar the change looks good, but could you add some tests to demonstrate the desired behavior?

Hi @coreysprague , I have added some test cases for parameter addition, removal, and update in groups.
Attaching screenshot of output for reference.


Add Jetson Nano Support

See thread starting at https://hub.mender.io/t/nvidia-tegra-jetson-tx2/123/10
Remaining steps:

[ ] Run the integration checklist on Nano
[ ] Resolve issue described here
[ ] Test on TX2

Just a detail, the commit message should be changed "Replace CONFIG_ENV_IS_NOWHERE with a CONFIG_ENV_IS_NOWHERE configuration"
It is obviously a typo and is supposed to be "Replace CONFIG_ENV_IS_NOWHERE with a CONFIG_ENV_IS_MMC configuration"

@moqmar thanks for these changes!
I tried to test on TX 2 this weekend but ran into 2 problems which I don't think are related to your changes.
This first problem: https://github.com/Trellis-Logic/meta-mender-community/pull/8 keeps me from being able to run tegraflash, attempts to run hang when writing the APP partition.  The workaround linked in that pull request gets around the issue for me, I still don't yet understand what changed or why this is necessary.
I have a second problem which results in this message on the serial terminal after mender-install-manual and redundant bootloader update:
[0000.147] C> Error: mts ratchet check failed

The boot halts after this, before even starting u-boot.
I'm not sure where this is coming from.  I rolled back to the last meta-tegra commit I thought I previously tested successfully, https://github.com/madisongh/meta-tegra/commit/6d41181d397984a9261558ab019827c51777286b and I see the same thing, with or without Nano changes included.
A mender -install on the command line without redundant boot component update works fine.
So, in summary, I think I'm convinced the problems I'm seeing on TX2 aren't related to your Nano changes.
@Ecordonnier I see your [comment on mender hub|https://hub.mender.io/t/nvidia-tegra-jetson-tx2/123/20] stating you tested mender update on tegra.  Can you confirm this was without mender-install-manual and redundant boot support?  Have you tried a tegraflash on TX2 yet?  I expect you'll need the change in  https://github.com/Trellis-Logic/meta-mender-community/pull/8 for this.

@dwalkes  I tested the update WITH redundant boot support / mender-install-manual, however I tested by flashing the tegraflash image (script doflash.sh) and not the dataimg, and I was testing with a custom image based on jetson-tx2. Are you testing with a custom image or with a standard yocto image?

@Ecordonnier
Thanks for the response.

Are you testing with a custom image or with a standard yocto image?

I was using core-image-minimal, based on a standard yocto image and the instructions in the meta-mender-community repository and repo tool..  I've previously used on a custom build successfully.
I just realized one difference from the last time I tried on the yocto image is I probably used core-image-base the first time I tried with Yocto.  I'll give that a try to see if I notice any difference.

FYI I am trying to make the branch work, as you know what still need to be done is to write the dataimg file to the data partition correctly. I pushed current state of my attempt to do this at https://github.com/taurob/meta-mender-community  (branch feature/jetson-nano). I am able to boot jetson-nano, but I can't mount the dataimg partition, so something is wrong:

bash-4.4# mount /dev/mmcblk0p15 /tmp
[ 1629.535764] EXT4-fs (mmcblk0p15): bad geometry: block count 507904 exceeds size of device (32768 blocks)
mount: /tmp: wrong fs type, bad option, bad superblock on /dev/mmcblk0p15, missing codepage or helper program, or other error.

I installed gptdisk manually to jetson-nano, and this is my partition table (looks good as far as I can tell):

Command (? for help): p
Disk /dev/mmcblk0: 62333952 sectors, 29.7 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 4A6B9FCA-0837-474A-BCF8-9C0F1E6F1186
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 33554398
Partitions will be aligned on 2048-sector boundaries
Total free space is 19518 sectors (9.5 MiB)
Number  Start (sector)    End (sector)  Size       Code  Name
1         4483072        33554398   13.9 GiB    8300  APP
2            2048            2303   128.0 KiB   8300  TBC
3            4096            4991   448.0 KiB   8300  RP1
4            6144            7295   576.0 KiB   8300  EBT
5            8192            8319   64.0 KiB    8300  WB0
6           10240           10623   192.0 KiB   8300  BPF
7           12288           13439   576.0 KiB   8300  TOS
8           14336           14463   64.0 KiB    8300  EKS
9           16384           17663   640.0 KiB   8300  LNX
10           18432           19327   448.0 KiB   8300  DTB
11           20480           20735   128.0 KiB   8300  RP4
12           22528           22687   80.0 KiB    8300  BMP
13           24576           24959   192.0 KiB   8300  ENV
14           26624         4220927   2.0 GiB     8300  APP_B
15         4220928         4483071   128.0 MiB   8300  DATA

There are occurences of "507904" in meta-mender, so I will try to investigate tomorrow what this error message means exactly.

I just realized one difference from the last time I tried on the yocto image is I probably used core-image-base the first time I tried with Yocto. I'll give that a try to see if I notice any difference.

core-image-base works fine, so this is just a problem with core-image-minimal.  I've added a note to the mender hub page known issues section.

Thanks @Ecordonnier

I pushed current state of my attempt to do this at https://github.com/taurob/meta-mender-community (branch feature/jetson-nano)

Thanks for sharing!

I am able to boot jetson-nano, but I can't mount the dataimg partition, so something is wrong:

The partitioning looks different than how it works on TX2 and I haven't had a chance to get into that difference in detail yet.  Do you understand how/where the sizes are getting filled in for each partition?  The TX2 uses size variables in flash_l4t_t186.custom.xml like APPSIZE for this, which is setup in a flash.xml.in file based on the meta-tegra image types class.  The data partition on TX2 uses a special 0x808 allocation attribute to assign all remaining space on the device to the data partition.
It looks like the sdcard-layout.mender.in has hard coded values for these and I'm wondering if this might be causing a disconnect about where the data partition is located or how it's sized.  For instance based on this section:
14,APP_B,2147483648,APPFILE
15,DATA,134217728,DATAFILE
1,APP,0,APPFILE

I think this means APP_B is fixed at 2G, DATA is fixed at 128MB and APP takes up the remaining space in the flash.  This appears to match your gptdisk output
Number Start (sector) End (sector) Size Code Name
1 4483072 33554398 13.9 GiB 8300 APP
...
14 26624 4220927 2.0 GiB 8300 APP_B
15 4220928 4483071 128.0 MiB 8300 DATA
...

I'm guessing this error:

[ 1629.535764] EXT4-fs (mmcblk0p15): bad geometry: block count 507904 exceeds size of device (32768 blocks)
means the DATA partition is larger than the amount of blocks you have reserved for it in the partition?  What does `ls` return for the size of your .dataimg file?  In my core-image base build it's `134217728`

dan@dan-ubuntu:~/mender-tegra$ ls -lsa build/tmp/deploy/images/jetson-tx2/.dataimg
348 -rw-r--r-- 1 dan dan 134217728 Dec 10 07:35 build/tmp/deploy/images/jetson-tx2/core-image-base-jetson-tx2--20191210143431.dataimg

which I don't think would fit in this space if sector size is 2K (127,268,864 bytes):

Number Start (sector) End (sector) Size Code Name
15 4220928 4483071 128.0 MiB 8300 DATA

Your understanding of the partitions is correct. 0 is a special value which means "maximum possible size". The .dataimg file is also 134217728 bytes big for my image, which is exactly 128 MiB, and exactly 32768 blocks of 4096 bytes. I didn't have time to work on this today, but the error shown (block count 507904 exceeds size of device (32768 blocks)) means that something is taking 2 080 374 784 bytes (507904*4096) instead of 128MiB. I am not expert in those low-level things, I checked the ext4 filesystem of the .dataimg file and it seems to have the correct size.
I will try to do a clean build, maybe something in my build files still has the old value of 2GB for the data partition (2GB is the value used in the original branch).

The problem is best shown with the dumpe2fs command. This is on my PC:
$ dumpe2fs ogrip-robot-jetson-nano.dataimg
...
Inode count:              32768
Block count:              131072
...
Block size:               1024

And this is on target:
# dumpe2fs -h /dev/mmcblk0p15
...
Inode count:              507904
Block count:              507904
...
Block size:               4096

I'm trying to fix it.

The remaining issue is that on jetson-tx2, the u-boot environment is stored in the boot partition of the emmc, but on jetson-nano which is using a sd-card, there is no emmc boot partition and therefore the configuration needs to be changed.
I started making the changes to move u-boot environment to its own partition at the beginning of the sd-card, and updated my branch, but it is not done completely (the branch does not compile, u-boot-tegra fails to compile with "#error CONFIG_ENV_OFFSET is not the same as MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_1".

Hi guys! Unfortunately I've been sick the last couple of days, but I'm trying to get this to work right now again. :)
Fixed the commit message & data partition, but there's still the issue left that partition sizes are currently hardcoded.

Hi Moqmar, I am not sure what you mean. I am working on moving the u-boot environment to the sd-card. As far as I understand other than that the partitions are working fine?

Basically, I'm trying to improve the workaround in https://github.com/taurob/meta-mender-community/commit/5967daa5c0dddcc32e0e5b8acbde6345332b629d so one can use a different partition size than 2GB (which is currently hardcoded in sdcard-layout-mender.in).
I haven't tried your latest commit yet, but moving around the partitions at the start always yielded an unbootable sd card for me, hence the out-of-order layout. I think ideally, the APP partitions should have an adjustable size (using IMAGE_ROOTFS_SIZE?!), and DATA should be at the end so it can be resized using the mender-growfs-data feature.
And sorry if the force push with the corrected commit message broke your fork, I think you'll have to do a rebase there...

OK, no problem about the rebase, that's very easy to do. The reason I moved the u-boot environment to the beginning, is that the "environment offset" variable of u-boot is 32 bits, so it cannot be more than a few GB after the start of the sd-card. I sent you an email with my phone number, if you want to discuss this quickly.

Yes, I read about that too - I think it works well if it's just after the system partitions though (which are all quite small), just before the APP/DATA partitions.

hm, ok, that could work. It will just make the offset calculation a bit more complicated.

I'm currently trying the approach from https://github.com/madisongh/meta-tegra/issues/188#issuecomment-545308006, will let you know if that worked out. The system partitions are hardcoded anyways, so that shouldn't be an issue.

Alright, now I'm a bit stuck at the following error message:
Failed to read the current active partition: No match between boot and root
partitions.: Failed mender_saveenv_canary check. There is an error in the U-Boot
setup. Likely causes are: 1) Mismatch between the U-Boot boot loader environment
location and the location specified in /etc/fw_env.config. 2) 'mender_setup' is
not run by the U-Boot boot script: exit status 1

I manually set echo '/dev/mmcblk0p13 0 0x2000' > /etc/fw_env.config, as suggested in the approach linked above - will have to add that to a recipe too.
I'm guessing that mender_setup is not being run? Or how can I check the environment directly in U-Boot?

I'm not sure what the state of your branch exactly is. By default, u-boot environment is configured to be in the mmcblk0boot1 partition, which does not exist on jetson-nano. Changing /etc/fw_env.config will only change the config in the rootfs, but u-boot will still be looking at the wrong place. That's why I started to configure "MENDER_UBOOT_CONFIG_SYS_MMC_ENV_PART_tegra210 = "0"", etc. in my tmp commits.

Or how can I check the environment directly in U-Boot?

I haven't tried on Nano yet but on jetson-tx2 you can use the u-boot console over a serial port cable.  Probably similar to these instructions.
Then from the u-boot console you can use commands printenv and setenv as described in the integration checklist or use u-boot commands (for the TX2 mtdparts is useful) to verify associated partitions.
Regarding the u-boot location changes it might be helpful to review the recent pull request for warrior which moved them on TX2 from the image into mmcblk0boot1.
See https://github.com/mendersoftware/meta-mender-community/pull/107.  Some of these changes might need to be backed out to support a different partition layout in Nano.  Let me know if you have any specific changes there.
I don't have a Jetson Nano currently but I might be able to get my hands on one next week.

Alright, managed to fix the error message with @Ecordonnier's approach. I'm currently trying it out and it seems like most things are working... It seems like I'm missing nvbootctrl though, which comes from tegra186-redundant-boot:
2019-12-12 14:04:25 +0000 UTC error: stderr collected while running script /var/lib/mender/scripts/ArtifactReboot_Enter_50 [Starting nvidia mender enter reboot redundant boot steps
/var/lib/mender/scripts/ArtifactReboot_Enter_50: line 5: nvbootctrl: command not found
]
2019-12-12 14:04:25 +0000 UTC debug: status reported, response 204 No Content
2019-12-12 14:04:25 +0000 UTC error: transient error: error calling enter script for (error) reboot state: error running enter state script(s) for ArtifactReboot_Enter state: statescript: error executing 'ArtifactReboot_Enter_50': 127 : exit status 127

Other than that, it seems to work quite well already. The rootfs is being updated (which is a bit weird, shouldn't it roll back on failure?), and mender says that it is running from the correct partition, but the kernel seems to still be the old one. The Directory Module is working perfectly, too.

I can confirm that the update is working (I'm attaching some logs showing a stand-alone update from git version "0c61fac-dirty" to "2ffe707-dirty" (of the repo importing meta-mender-community as submodule) which shows a boot on /dev/mmcblk0p1, and then a boot on /dev/mmcblk0p15 after the reboot. I don't see an error related to nvbootctrl when doing a stand-alone update with the command "mender -install", are you testing using a mender server? I think on jetson-nano we should not call nvbootctrl at all, as long as the update of the bootloader is not implemented (redundant boot).
Also, I find your comment regarding the fact that the kernel is not updated surprising, because the kernel is located in the /boot directory of the rootfs and is not a separated partition on jetson-nano. Therefore if the rootfs gets updated the kernel should be updated too.
log-update-mender.txt

You're right, seems like the kernel indeed did update, I just did something wrong when disabling a module. \o/
So, it seems like the best thing to do would be to just disable the redundant-boot-reboot-state-script on the Jetson Nano, I'm currently trying to figure out how to do that. Other than that, it seems like everything's working. :smile:

How are you testing? I don't see the redundant-boot-reboot-state script being called in my logs.

This is when using the Mender Server - the file doesn't exist under the specified path though, so I'm a bit unsure where that error is coming from... The final deployment status is Failure: start executing script: ArtifactReboot_Enter_50

I wonder if maybe your build state is not correct, because in commit "Remove BUP Payload dependency" you indeed removed the dependency to "mender-tegra-bup-payload-install" which is deploying ArtifactReboot_Enter_50, but maybe the file was still left in your tmp folder.
What do you have there?
root@jetson-nano:/etc/mender# ls scripts/
version
root@jetson-nano:/etc/mender# ls /data/mender/scripts/
version

Oh, you're right, bitbake -c clean tegra-state-scripts fixed the issue, thanks a lot! 😃

OK great! I also checked the values in /etc/fw_env.config and it seems to be consistent with the ENV partition start sector reported by gdisk:
root@jetson-nano:~# cat /etc/fw_env.config
/dev/mmcblk0 0xc00000 0x20000
/dev/mmcblk0 0xc20000 0x20000

gdisk shows:
  13           24576           24959   192.0 KiB   8300  ENV
And 24576*512 is 12582912 which is 0xc00000, so I think the u-boot environment is not overwriting anything it should not.
I'm going to test on jetson-tx2 today. Will you send a pull-request to the upstream repo?

I confirm that stand-alone updates are working fine with commit b91ba8a1a85 of meta-mender-community and 0c4783ebbf5606 of meta-mender (warrior branch) on jetson-tx2. I tested using mender-install-manual, which also updated the bootloader.

Thank you @Ecordonnier and @moqmar!
I see the latest commits in the branch at https://github.com/taurob/meta-mender-community/commit/b91ba8a1a85732d9000b6bf32506664e2b979d22 and changes at https://github.com/Trellis-Logic/meta-mender-community/pull/9
I've added a couple of review comments there, I'm curious about the u-boot environment offset.
I also noticed this note

I also generally checked the things listed in the integration checklist except for rollback (they all seem to be working fine), but couldn't do it directly as shown in the instructions as I don't have a serial cable here.

I think it will be important to do the u-boot steps and test rollback to be sure it's working.  My concern (see code review comments above) is that you might not be writing the ENV partition and u-boot environment might be overwriting other partitions used for tegra boot.
I think the next step would be either for @Ecordonnier to open a PR for nano suport on meta-mender-community using the taurob branch or @moqmar to merge the taorb branch into his repo and open the PR from there.
Note that you'll need to follow the Contributing guidelines (see signing and commit format instructions there).
Can either or both of you support the Nano going forward?  If so, please add your names to the Maintainer section of the readme
Finally, I think we'll need to either add a new mender hub page for the Nano, linked from https://hub.mender.io/t/nvidia-tegra-jetson-tx2/123, or merge the Nano into that page.  Perhaps we should ask Mirza what they'd prefer.
I'm planning to understand and fix https://github.com/Trellis-Logic/meta-mender-community/pull/8 next week, and also try the Nano changes myself.

@moqmar  today I cleaned-up the branch and reduced it to a single commit with both our "sign-off" (https://github.com/Trellis-Logic/meta-mender-community/commit/76b99ed7a2b8fd11d935c835521d1503b7fceda1). I also created the documentation at https://hub.mender.io/t/nvidia-tegra-jetson-nano/1360
I cannot commit to being a maintainer of the jetson-nano more than a few weeks for various reasons, so I did not add my name to the maintainer's list. Is it OK for you if I send a pull request with this commit? You can also do it if you prefer.

Sure, go ahead! 👍
I won't be able to officially maintain it either though, as I'm only working with the Jetson until March for research purposes, but it's great that it's working so far right now. 😃

@moqmar Great, I created https://github.com/mendersoftware/meta-mender-community/pull/119 and you are the author of the commit.

Closed in favor of https://github.com/mendersoftware/meta-mender-community/pull/119


vulnerability in docker image (cve-2022-28391)

Hi, there's a vulnerability in your docker images you're publishing to dockerhub. The vulnerability is from busybox and is documented here.

Thanks for reporting @nathanloyer. I will take a look for respective patched alpine version

Thanks for the report @nathanloyer. A new version was released as 0.1.17-2 release and published to the Docker Hub


arm: soc: NXP: Enable SEGGER RTT on all NXP SoCs

It seems like SEGGER is supported across all the NXP SoC families so
lets enable it across all of them.
Signed-off-by: Kumar Gala<EMAIL_ADDRESS>

Codecov Report

Merging #7218 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #7218      +/-   ##
==========================================
- Coverage   55.03%   55.02%   -0.01%
==========================================
  Files         477      477
  Lines       51744    51744
  Branches     9949     9949
==========================================
- Hits        28475    28474       -1
- Misses      19306    19307       +1
  Partials     3963     3963

Impacted Files
Coverage Δ

lib/posix/pthread.c
69.34% <0%> (-0.51%)
:arrow_down:

Continue to review full report at Codecov.

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