Deployment Hook

Current projects execute a lot of commands when deploying  Shopware. Shopware-cli should abstract it and make it easy as possible:
Build Hook
This is kinda of our shopware-cli project ci command.
New to this step, we generate a deployment-manifest
This deployment manifest contains some meta information we might need in the deploy hook like:

Changes files (so we can skip steps, like updating plugins, compiling theme)

Before Hook

Uninstall plugins, which will be removed in next deploy?

We can't uninstall a Plugin when the source code is missing

Deploy Hook
Tasks:

Install or Update Shopware
Install, Update, or Activate Plugins
Compile the Storefront Theme if needed
Copy assets if an external storage is used

We should allow to run custom commands to do custom stuff.

Maybe just allow running bash scripts or inline in our config?
Or we use something like starlark to add fancy wrapper

I love the idea - although I would prefer to implement it in deployer 🙈  But overall this is awesome! And the "uninstall a plugin before removing it" is a problem we just encountered. Thankfully only once.

That is the exact reason why it should not be implemented into the deployer. Deployer is one "the tools". We don't want to implement this specific for each tools, the tools should use this :)

I love the idea too, though it sounds a real challenge to me. Deployment is a complex process.
When I look at my procedures for different projects at different hosters (cloud, traditional hosters like Profihost, maxcluster ...) I'd say some 2/3rd to 3/4th of the task is server technology related (like setting ownership and permissions, make switched symlinks work etc.), so Shopware related stuff is just the minor part (no real challenge by itsefl, though a some more documentation would not be wasted :smile:)
For the server related stuff, I still believe bash is the most efficient and shortest way to go. My gitlab or bitbucket script for the runner part is typically just a handfull of lines. The bash script for the target server business on the other hand typically around 70 lines. (I never understood how deployer is of use here - just adds complexity in my mind.) The server specific requirements are just so diverse (starting with the question under which user the deployment runs, and is a root, or just sudo, identical with webserver user or not ...)
But what I really miss, is some kind of "version management" for those things in a deploy, like the uninstall/install of plugins, that need only to be done in connection with a specific commit. So something that would allow to track what was changed in the system (plugin install/uninstall, config settings) over time/commit history. (For example, if, with one commit I'd install a new plugin, I would have to put the install for this plugin within my deployment script, and then take it out again with the next commit - whichever that is. This is clumsy and difficult to track.)
Ideally, my deployment script should look for some instructions similiar to a db migration, and just apply it once. I guess this it what you have in mind with the pre and post deploy hooks? But it must have this "only once" functionality. So in essence, this would just be a kind of - let me call it that - "cli installation migration" command.

i would prefere a version that is independent to deployer or other similar tools, too. We are facing the challenge that new customers often need tailored solutions for their deployments. So something that only depends on shopware-cli is a good thing :)
Things our deployment does with own commands using bin/console

Composer Install
Build administration and storefront
Run DB Migrations (shopware itself)
Plugin Refresh, Plugin Updates (with some jq magic to only update when version changes)

Plugins are managed only via composer, removing them is only done through composer

Restart messengers
compile themes
cache clears

All deployments happen with some sort of release directory and switch the htdocs symlink if all above steps are successfull. So we don't really need a check if some files are changed and only then compile the theme - the cache folders inside the release folder and not shared, so it will always be necessary to compile the js, css and themes up till now.

I assume make and bash are sufficient. I do not see a reason to install yet another deployment support tool.

I am with you @JoshuaBehrens , but bash and UNIX tools aren't really portable. There is bsd/musl/glibc variants of grep, awk which makes portable bash scripts kinda impossible

I do have issues between MacOS and debian binaries. I cannot/will not deny it :D but I am hardly on any other environment and thus I would not use shopware-cli for that. I fear, that eventually I would have to do pull requests in Go to change e.g. order of scripts executed and wait for a binary, that needs to be built and shared. And for that there are already scripting solutions, that are more flexible (bash / php).

What would you guys think about having a additional composer package shopware/maintenance or something like that. Which brings a new vendor/bin/shopware-maintaince command line with abstracts the command execution and allows to configure further things with a .shopware-project.yaml

This would improve a way to get the binary. Right now I have this in my makefiles:
UNAME := $(shell sh -c 'uname -s 2>/dev/null || echo not')
ifeq ($(UNAME),Linux)
	SHOPWARE_CLI_ARCHIVE := https://github.com/FriendsOfShopware/shopware-cli/releases/download/0.4.29/shopware-cli_Linux_x86_64.tar.gz
endif
ifeq ($(UNAME),Darwin)
	SHOPWARE_CLI_ARCHIVE := https://github.com/FriendsOfShopware/shopware-cli/releases/download/0.4.29/shopware-cli_Darwin_arm64.tar.gz
endif
SHOPWARE_CLI_FILE := dev-ops/bin/shopware-cli

.PHONY: clean
clean: ## Cleans up all ignored files and directories
	[[ ! -f $(SHOPWARE_CLI_FILE) ]] || rm -f $(SHOPWARE_CLI_FILE)

.PHONY: build-assets
build-assets: $(SHOPWARE_CLI_FILE) ## Builds assets
	$(SHOPWARE_CLI_FILE) extension build .

$(SHOPWARE_CLI_FILE): ## Install shopware-cli executable
	$(CURL) -L $(SHOPWARE_CLI_ARCHIVE) -o $(SHOPWARE_CLI_FILE).tar.gz
	cd $(dir $(SHOPWARE_CLI_FILE)) && $(TAR) -xvzf $(notdir $(SHOPWARE_CLI_FILE)).tar.gz shopware-cli
	rm $(SHOPWARE_CLI_FILE).tar.gz

This will be solved in https://github.com/shopwareLabs/deployment-helper


Upgrade gradle version

Signed-off-by: shaishavgandhi05<EMAIL_ADDRESS>

Just merged #5 which fixes this issue.  Thanks for pointing this out and helping us fix it!


[Q] Differents between SourcePersisiter and FileSystemPersisiter?

Hello dev:
what is the differents between SourcePersister and FileSystemPersister?

They are just about the same. One works on Barcodes only while the other can work on a key of any type. We keep both for backward compatibility

@digitalbuddha
Thanks your expain explain.


CLA status reporting not working

first this https://github.com/iron-io/functions/pull/637
then this https://github.com/iron-io/functions/pull/640
looks similar to #77

@KharitonOff can you please have a look into this ?

Seems to be happening to me as well. Last PR CLA-Assistant was active on was 7 days ago here. Worth noting that that was just a comment, and that PR doesn't have a CLA check.
After that we've had a few PRs with no word from the bot. And clicking the 'Recheck PRs' button in the settings panel does nothing...
Current PRs:https://github.com/MinecraftForge/MinecraftForge/pull/4339 https://github.com/MinecraftForge/MinecraftForge/pull/4336
It seems things started to break 17/18 days ago. As this PR has the CLA check but this doesn't.

@c0ze Sorry for that and for the late response. I'm currently on vacation, that's why I could not react in time and I still have limited access to analyse the problem.
If your problem is related to the issue #77 (wrong access token), then you can just log in to cla-assistant.io and a new token will be stored for your repos.
If there are some problems with the webhook on github, you can either check it in github directly (repository settings -> webhooks) or just remove the link for your repo in cla-assistant.io and create it again (all signatures remain active as long the gist file keeps unchanged).
I have also noticed that the name of your CLA status is obsolete, see the #211
@c0ze @LexManos As soon as I am back from vacation I'll check the logs and source code on my side.

Hate to bump this, but I have no idea how long you're on vacation. But it's been 10 days. Any update on this?

My problem has been solved after deleting the link and recreating again.
It seems my problem was about the #211 .
(Make sure to export your contributions before deleting your link if you're going about this route.)

@LexManos CLA assistant has indeed wrong/outdated token stored for your repository. I've changed the token-update mechanism. The workaround from @c0ze would solve the issue in your case, but I hope you haven't tried it yet :) If not, it would be very helpful if you would logout and login into CLA assistant and trigger the "Recheck PRs" button.

@c0ze glad to hear, that your problem is solved now! 👍  Sorry for the inconvenience!

@KharitonOff Thanks for taking a look, I was out of town for PAX this weekend and didn't have time to check in on this.
However, Relogging and hitting recheck seems to of worked. I did not try the workaround. So that's good.
Just a suggestion it would be cool to see some form of progress/feedback for the recheck button. As right now it just clicks and freezes the page for a second. But seems to of worked.


Sometimes got error of  RCTNetworking.sendRequest() not found

error message is like:
Invariant Violation: Callback with id 1: RCTNetworking.sendRequest() not found

it repeated over 21 times...

I get the same error when I have multiple Chrome debugger tabs open.
Here is the console log in Chrome:

@jordanranz so am I, debugger tab will automatically open..

Same problem here, and I'm running the debugger on the unaltered Movies example from https://github.com/facebook/react-native/tree/master/Examples/Movies. Using OS X and Chrome.

Closed multiples of Chrome debugger like @jordanranz said. Worked for me.

The multiple tabs of Chrome debugger was breaking it for me as well. Closed all but 1 of them and now it works fine.

It is still annoying that Chrome windows pop sometimes...

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/sometimes-got-error-of-rctnetworkingsendrequest-not-found-
ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub. GitHub issues have voting too, nevertheless
Product Pains has been very useful in highlighting the top bugs and feature requests:
https://productpains.com/product/react-native?tab=top
Also, if this issue is a bug, please consider sending a pull request with a fix.
We're a small team and rely on the community for bug fixes of issues that don't affect fb apps.


fix(ci): fixed update-syscalls syscalls-bumper action version.

What type of PR is this?
/kind bug
Any specific area of the project related to this PR?
/area CI
Does this PR require a change in the driver versions?

/version driver-API-version-major

/version driver-API-version-minor

/version driver-API-version-patch

/version driver-SCHEMA-version-major

/version driver-SCHEMA-version-minor

/version driver-SCHEMA-version-patch

What this PR does / why we need it:
Should fix failing ci: https://github.com/falcosecurity/libs/actions/runs/7054960824/job/19204648324
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/milestone 0.14.0

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, incertum
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP,incertum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@FedeDP: Closed this PR.

In response to this:

Closign and reopening to trigger tide...
/close

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

/reopen

@FedeDP: Reopened this PR.

In response to this:

/reopen

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

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, FedeDP, incertum
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97,FedeDP,incertum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Adds the newly added entity domains: event, lawn_mower, todo and wake_word

Add the newly added entity domains to the core:

event
lawn_mower
todo
wake_word

I'll merge this later as I can't update the sheet accordingly right now

Oh shit I forgot about this PR, I'll put it in my to do list for Thursday

Sorry 🙏

No problem, since then there have been several other new entity domains, so it needed to be revised.


Limit and offset not work in subquery

JPQLQuery<String> rid = JPAExpressions.select(table.rowid).from(table).where(predicate, builder).limit(pageSize).offset(offset);

Limit and offset not work in it if i use .where(table.rowid.in(rid))

Its generally not supported in JPA

List<String> rids = jpaQueryFactory.select(violation.rowid).from(violation).where(predicate, builder).limit(pageable.getPageSize()).offset(pageable.getOffset()).fetch();
List<Violation> list = jpaQueryFactory.selectFrom(violation).where(violation.rowid.in(rids)).fetch();

I think it may be able to support to merge two query with one?

Closing as it's not an issue with Querydsl. Feel free to ask for help in the Google group/StackOverFlow etc. :)


Documentation issue: Getting started

Do you want to share what the issue is? Without a description, I can't really do anything 🙂

Closing this as I need further details to act on this.


Update ui-util to upstream androidx version

Hi. In upstream androidx maintained by Google androidx.compose.ui:ui-util it contains additional functions not present in JetBrains compose-multiplatform-core. Is there any reason why the JetBrains variant is out of date? As far as I could tell there should be very little work needed to get it fully multiplatform. Reason I ask is because I could make use of these in a library I'm developing.

What version of androidx.compose:ui are you interested? If you mean 1.6.3, then the next Compose Multiplatform release 1.6.1 will contain its changes.

I mean the ui:ui-util project is behind, the ui:ui project is up to date. I'm unsure which version ui-util in compose-multiplatform-core is on

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


RLocalCachedMap.containsKey doesn't fire loader

Expected behavior
containsKey looks for a key in local cache, then in redis, and, at last, invokes loader. If loader returns entry, put it in cache and report true.
Actual behavior
containsKey doesn't invoke loader at all and returns false for cold local cache/redis.
Steps to reproduce or test case
I have a map with loader, however for cold local cache and cold redis, this snipped produces different output
    final override fun isExists() = instrumentMap.containsKey(instrumentId)
    final fun isExists2() = instrumentMap[instrumentId] != null

The first one is false if cache + redis is empty, loader is not invoked. The second call invokes loader and populates cache. Subsequent containsKey calls start to work after that.
Probably, other Map implementations contains this issue.
Redis version
6.0
Redisson version
3.15.5
Redisson configuration
Single server, LocalCachedMapOptions.defaults() with loader.

Fixed! Thanks for report


Copy button is broken on files view

<EMAIL_ADDRESS>The copy button does not work.

Fixed


Change the request Payload type into byte[] for MediaType application/octet-stream in client generations

Description:
As per discussion https://github.com/ballerina-platform/openapi-tools/issues/815#issuecomment-1380055179 current client generations change into byte array
example openapi
openapi: 3.0.0
info:
  title: refComponent
  description: refComponent
  version: 1.0.0
servers:
  - url: http://petstore.{host}.io/v1
    description: The production API server
    variables:
      host:
        default: openapi
        description: this value is assigned by the service provider
  - url: https://{subdomain}.swagger.io:{port}/{basePath}
    description: The production API server
    variables:
      subdomain:
        default: petstore
        description: this value is assigned by the service provider
      port:
        enum:
          - '8443'
          - '443'
        default: '443'
      basePath:
        default: v2
paths:
  /user:
    post:
      summary: Creates a new user.
      responses:
        200:
          description: OK
      requestBody:
        content:
          application/octet-stream:
            schema:
              type: string
  /payment:
    post:
      summary: Creates a new payment.
      responses:
        200:
          description: OK
      requestBody:
        description: Details of the pet to be purchased
        content:
          application/octet-stream:
            schema:
              $ref: '#/components/schemas/Pet'
components:
  schemas:
    User:
      type: object
      required:
        - userName
      properties:
        userName:
          type: string
        firstName:
          type: string
        lastName:
          type: string
    Pet:
      type: object
      required:
        - userName
      properties:
        userName:
          type: string
        firstName:
          type: string
        lastName:
          type: string
    PetForm:
      type: object
      required:
        - userName
      properties:
        userName:
          type: string
        firstName:
          type: string
        lastName:
          type: string

Current generation
# Creates a new user.
    #
    # + return - OK
    resource isolated function post user(string payload) returns http:Response|error {
        string resourcePath = string `/user`;
        http:Request request = new;
        request.setPayload(payload, "application/octet-stream");
        http:Response response = check self.clientEp->post(resourcePath, request);
        return response;
    }
    # Creates a new payment.
    #
    # + payload - Details of the pet to be purchased
    # + return - OK
    resource isolated function post payment(Pet payload) returns http:Response|error {
        string resourcePath = string `/payment`;
        http:Request request = new;
        request.setPayload(payload, "application/octet-stream");
        http:Response response = check self.clientEp->post(resourcePath, request);
        return response;
    }

expected code generation
# Creates a new user.
    #
    # + return - OK
    resource isolated function post user(byte[] payload) returns http:Response|error {
        string resourcePath = string `/user`;
        http:Request request = new;
        request.setPayload(payload, "application/octet-stream");
        http:Response response = check self.clientEp->post(resourcePath, request);
        return response;
    }
    # Creates a new payment.
    #
    # + payload - Details of the pet to be purchased
    # + return - OK
    resource isolated function post payment(byte[] payload) returns http:Response|error {
        string resourcePath = string `/payment`;
        http:Request request = new;
        request.setPayload(payload, "application/octet-stream");
        http:Response response = check self.clientEp->post(resourcePath, request);
        return response;
    }

Steps to reproduce:
Affected Versions:
OS, DB, other environment details and versions:
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

Closing with https://github.com/ballerina-platform/openapi-tools/pull/1192


Owners of the repo can release other executables instead of the real one
But he just decompiled a Roblox executor and claims this project is a virus because of that?
I don't get his thinking process behind it but the Roblox exploit part should explain it

He fr decompiled a Random Github Binary and now things hes a pro Hacker 💀
Bro is crazy autistic.

so guys someone got into my paypal account two days ago can this be the reason ?

are u retarded

hes yapping


Any way to find out our server's address?

client -> socks (<IP_ADDRESS>) -> destination.example.com
Is there a way to find out which address the client used to connect to the socks server (<IP_ADDRESS>)? Or which of the server's IP addresses the connection was made to, when more are available?

Interested in this as well. Why did you close the issue? :)

socket.remoteAddress?

@ciokan I was interested what the local ip address was used when bound to <IP_ADDRESS>, but I realized it's not a question for this project. socksv5 uses nodejs sockets and my question is not this project's responsibility, it's a nodejs question really.


new helm-chart with helmet subchart

Hi @chenhunghan,
i created a new helm-chart with helmet.
It allows to configure a helm-chart with less boilerplate. The reason why i created a new chart is that the release-name is also the deployment name and the service name on the old chart. So if i have two different Charts with the same release-name the .yaml is rejected.
I do not need this change merged but i also do not want to have it alone on my disk.
It's more a proposal which we/i can fine tune (e.g. readme) if you are interested in.

Thank you, the helmet approach seems good, and good point on the release name.

HI @chenhunghan
anything to do here from my side?

Need to fix the lint error, otherwise LGTM.

Okay, thanks, will add it to my todo.


Fixing a typo found in a backport

Summary
Addressing https://github.com/rancher/dashboard/pull/12419#pullrequestreview-2408518863
Checklist

[x] The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
[x] The PR has a Milestone
[x] The PR template has been filled out
[x] The PR has been self reviewed
[x] The PR has a reviewer assigned
[x] The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
[x] The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

@codyrancher Do we want to get this in for 2.10.0 ?

@codyrancher Do we want to get this in for 2.10.0 ?

No, I marked for 2.11. It only affects code and nothing the customers will see.

Okay thank you


Left hand side of tournaments are cropped

First round/match is half visible.
In portrait orientation it is hidden entirely.

Assumption: this could be related to a recent change to centre the content with the flex box, revert this change - or only use it when there are no rounds.


Testing

trimming down the slide implementation because its no longer useful

This is pretty good, I'm kinda busy so instead of leaving a comment I will just accept it and then change it later and we can talk about it tomorrow.


Adding "preview" Status.

Adding the "preview" status which is listed in the submission rules here: https://github.com/mlperf/policies/blob/master/submission_rules.adoc#73-results-categories

Submitting live during SWG.


bug(python): optimize_indices cannot be called on vector index with cosine distance type

LanceDB version
0.8.1
What happened?
I'm trying to call optimize_indices on a dataset that has a vector index with cosine metric/distance type.
I'm hitting the following error:
KMeans::compute_partition: distance type cosine is not supported

From what I can tell, compute_partition doesn't actually seem to support a cosine distance type:
https://github.com/lancedb/lance/blob/526cdd186b0f2fcb840477ac7bfb6f359c5137d7/rust/lance-linalg/src/kmeans.rs#L692-L712
Are there known steps to reproduce?
No response

This is fixed by https://github.com/lancedb/lance/pull/2698, which is part of the latest release of lance ^1. It will be included in the next release of LanceDB.


typecheck error Cannot find type definition file for 'node'.

Environment

Operating System: Darwin
Node Version:     v18.13.0
Nuxt Version:     3.1.1
Nitro Version:    2.1.0
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      typescript
Runtime Modules:  -
Build Modules:    -

Reproduction
npx nuxi init nuxtissue
cd nuxtissue
npx yarn install
npx nuxi typecheck

Describe the bug
error TS2688: Cannot find type definition file for 'node'.
  The file is in the program because:
    Entry point of type library 'node' specified in compilerOptions

Found 1 error.

 ERROR  Command failed with exit code 2: npx -p vue-tsc -p typescript vue-tsc --noEmit

Additional context
No response
Logs
No response

A reproduction would be nice. Generally you can fix it by adding @types/node as a dev dependency.

The commands to reproduce the issue are in the "Reproduction" section.  To be explicit:

open a new terminal window

create a new project:

npx nuxi init nuxtissue

enter the project directory

cd nuxtissue

install dependencies

npx yarn install

try to typecheck

npx nuxi typecheck

https://nuxt.com/docs/api/commands/typecheck#nuxi-typecheck mentions the typescript and the vue-tsc requirement but not @types/node.

/cc @danielroe Shall we add note types to starters?

💯 Done inhttps://github.com/nuxt/starter/commit/c16b3201c3f70cba9a9eabd49d04cbcacfba5864.

I've also added a comment in the docs: 6b2bc680b06ffbbc7383c428f7e535bdbf1754b9. When we add new nypm integration it would be nice to offer to auto-install these dependencies.


Unavailable

Version of the custom_component
0.22

Configuration

I don't have anything in my config for govee...

Describe the bug
The device is unavailable and has been for about a week. I can control it via the Govee App.
I tried updating my API. As soon as I got a new API it did seem to start giving errors. When I updated the api, in the logs it seems to be working, but the API itself was working fine before i requested a new key, from what I can tell. Its just remains unavailable.
I deleted the integration, rebooted, re-downloaded from HACS, rebooted and added and my new device was immediately unavailable.
About 3 days ago i updated the polling setting (first to 300, then to 150) and am now using 200. It hasn't been available for at least a week.
Debug log

2022-06-18 21:48:40 WARNING (SyncWorker_2) [homeassistant.loader] We found a custom integration govee which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2022-06-18 21:50:16 DEBUG (MainThread) [govee_api_laggat.govee_api_laggat] govee_api_laggat v0.2.2
2022-06-18 21:50:16 DEBUG (MainThread) [govee_api_laggat.govee_api_laggat] get_devices
2022-06-18 21:50:16 DEBUG (MainThread) [govee_api_laggat.api] get_devices
2022-06-18 21:50:17 DEBUG (MainThread) [govee_api_laggat.govee_api_laggat] govee_api_laggat v0.2.2
2022-06-18 21:50:17 DEBUG (MainThread) [govee_api_laggat.govee_api_laggat] get_devices
2022-06-18 21:50:17 DEBUG (MainThread) [govee_api_laggat.api] get_devices
2022-06-18 21:50:17 WARNING (MainThread) [custom_components.govee] API is back online.
2022-06-18 21:50:17 INFO (MainThread) [custom_components.govee.learning_storage] Loaded learning information from /config/govee_learning.yaml.
2022-06-18 21:50:17 DEBUG (MainThread) [custom_components.govee.light] Setting up Govee lights
2022-06-18 21:50:17 DEBUG (MainThread) [custom_components.govee.light] _async_update
2022-06-18 21:50:17 DEBUG (MainThread) [govee_api_laggat.govee_api_laggat] get_states
2022-06-18 21:50:17 DEBUG (MainThread) [govee_api_laggat.api] state returned from API: {'data': {'device': '5C:80:A4:C1:38:CC:F3:72', 'model': 'H6110', 'properties': [{'online': 'false'}, {'powerState': 'off'}, {'brightness': 9}, {'color': {'r': 255, 'b': 0, 'g': 0}}]}, 'message': 'Success', 'code': 200}, resulting state object: GoveeDevice(device='5C:80:A4:C1:38:CC:F3:72', model='H6110', device_name='Kian', controllable=True, retrievable=True, support_cmds=['turn', 'brightness', 'color', 'colorTem'], support_turn=True, support_brightness=True, support_color=True, support_color_tem=True, online=False, power_state=False, brightness=22, color=(255, 0, 0), color_temp=0, timestamp=1655603417.44828, source=<GoveeSource.API: 'api'>, error=None, lock_set_until=0, lock_get_until=0, learned_set_brightness_max=100, learned_get_brightness_max=100, before_set_brightness_turn_on=False, config_offline_is_off=False)
2022-06-18 21:50:17 DEBUG (MainThread) [custom_components.govee.light] Finished fetching govee data in 0.046 seconds (success: True)
2022-06-18 21:53:37 DEBUG (MainThread) [custom_components.govee.light] _async_update
2022-06-18 21:53:37 DEBUG (MainThread) [govee_api_laggat.govee_api_laggat] get_states
2022-06-18 21:53:37 DEBUG (MainThread) [govee_api_laggat.api] state returned from API: {'data': {'device': '5C:80:A4:C1:38:CC:F3:72', 'model': 'H6110', 'properties': [{'online': 'false'}, {'powerState': 'off'}, {'brightness': 9}, {'color': {'r': 255, 'b': 0, 'g': 0}}]}, 'message': 'Success', 'code': 200}, resulting state object: GoveeDevice(device='5C:80:A4:C1:38:CC:F3:72', model='H6110', device_name='Kian', controllable=True, retrievable=True, support_cmds=['turn', 'brightness', 'color', 'colorTem'], support_turn=True, support_brightness=True, support_color=True, support_color_tem=True, online=False, power_state=False, brightness=22, color=(255, 0, 0), color_temp=0, timestamp=1655603617.259576, source=<GoveeSource.API: 'api'>, error=None, lock_set_until=0, lock_get_until=0, learned_set_brightness_max=100, learned_get_brightness_max=100, before_set_brightness_turn_on=False, config_offline_is_off=False)
2022-06-18 21:53:37 DEBUG (MainThread) [custom_components.govee.light] Finished fetching govee data in 0.259 seconds (success: True)```

Thanks for your help

Oh wow, I was getting thrown off by being able to connect to it via the app, and the api seemingly working. I forgot it has bluetooth connectivity as well, even though I saw in the logs it said online: false.
I just needed to reconnect the wifi in the govee home app. Not sure why it dropped, its working now.

I am unable to get it to connect right now. I have gotten new API and it doesn't work and neither does the old one. I also have been dealing with issues of the lights constantly disconnecting from the internet. I have to reopen the app and connect to each device over bluetooth to get them working again.

I had the same issue, but was able to fix it.
For about a week or so, my Govee devices have been consistently unavailable in HA (even though they're all available in the Govee app. Looking at the logs, it just says "Cannot communicate with API" setup failed).
I contacted Govee and asked them to regenerate a new API key for me (took about 12 hours for them to reply). It is now working again. If I had to take a wild guess, maybe my API key was too old (I've been using it for years)

FYI - It seems there is a secondary problem when you start adding more devices... API rate limits.
Error:
Could not connect to Govee API: API: API-Error 429: {"message":"rate limited! the limit is 10000 requests every 24 hours. X-RateLimit-Reset in Http Response Header shows the reset time."}

I have changed my polling interval to 20 in the hopes it gives me some more breathing room

Hello everyone! My Govee the issue of the connection with HA was solved.
Since July 7 I have no more connection problems and seeing the time it was solved, the only thing I did was restart the Router due to another problem I was having.
I hope this helps you solve your issue.


Error "Could not resolve resource" in VS Code Extension

Using Azure Resources VS Code extension v0.9.9, trying to expand a resource group in explorer. Get multiple of these errors:
info] Internal error: 'branchDataProvider.getResourceItem' threw an exception
	Could not resolve resource "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Web/sites/<logic app name>"
		at CompatibleApplicationResourceBranchDataProvider.<anonymous> extension.bundle.js:2:1727792
		fulfilled extension.bundle.js:2:1726817

If you revert to past versions of Azure Resources, does the issue still reproduce? Are there any more logs in the Azure Resources log output channel?

@alexweininger yes reproduces on e.g. version 0.9.7. The above error repeats on every resource in the group, but there's no additional detail to add. Is there a way to get more verbose logging to track down the cause?

Ok, thanks for that information. For logs, you can check the Azure Resource Groups output window, and also the output windows of Logic Apps.


🧄🧅

Add garlic (🧄) and onion (🧅) entries

Care to explain?

Care to explain?

They were added via #178 along with all the 13.0 emoji.
https://github.com/muan/emojilib/blob/1d900a237a66343a1e893cb691e97b36e6b78682/dist/emoji-en-US.json#L4209-L4214

They were added via #178 along with all the 13.0 emoji.
https://github.com/muan/emojilib/blob/1d900a237a66343a1e893cb691e97b36e6b78682/dist/emoji-en-US.json#L4209-L4214

Got it, thanks!

Got it, thanks!


Investigate the formatting tool for the project

It is very important to have a good coding standard. It helps to keep the code simple and clean. A nice formatted code is easier for people to understand, review, compare, maintain and update. We should investigate a good formatting tool for the project.
Below are some of the requirements:

easy to use
integrates well with different IDEs
support multiple languages (js, JSON, CSS,  etc)

Possible tool: https://prettier.io/

I'd love to investigate on the tool

Here are some potential formatting tools for the project I have found.
Prettier:

Supports: JavaScript, Flow, TypeScript, CSS, SCSS, Less, JSX, GraphQL, JSON, Markdown with plugins you can use it for Python, PHP, Swift, Ruby, Java and more
Integrates with most editors: VS Code, Sublime Text, Atom, Espresso, Visual Studio, WebStorm, formatter applied every time change is saved
Enforces proper consistent styling of the codebase across the entire codebase: maintainability of large-size code

CodeBeautify

Used by companies like Facebook, Spotify, Discord, PayPal…
Supports conversion between Json, HTML, XML, YAML to other languages.
Supports beautifying tools for JSON, CSS,  XML, Java, etc.
Methods: File upload, URL, coy and paste
Chrome extension version exists

RubyMine

Support for Ruby and Rails, JavaScript, CoffeeScript, ERB, HAML, CSS, SaSS and LESS, and more
Supports code formatting and code completion
Helps maintain required code style

Able to configure code style settings for every language in a project.

Language Specific
Java:

Java code formatter in IntelliJ: eClint https://github.com/jedmao/eclint - configured using .editorconfig file

Python:
Black

Uses the black code style
Can be installed by pip install black - unix style command line tool
Able to read project-specific default values for its command line options from a pyproject.toml file

Thanks @yinggzz !  Based on our discussion today, you and @llxia have a few additional activities on this one, focussing on Prettier and CodeBeautify.  Think about what we would expect of contributors to this repository.  Would we 'enforce' formatting with a PR check?  Are their github actions that would allow for this as part of a workflow?  If we do not enforce it, is this mainly about creating a template and document guidelines?

The goal is this task is to find a formatting tool that can format automatically for the users. Ideally, the PR should be formatted well before users submit the PRs. I would expect that there is no or minimal work for both users and reviewers for formatting.

CodeBeautify is not what we are looking for. It is a third-party online tool that users have to manually format their files on its site.

Using Prettier as an example, we can check in our formatter file in the repo. And users can just install Prettier for their IDE (i.e., Formatter for Visual Studio Code https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode). Once it is installed and configured (one-time configuration setup), the files will be auto-formatted at saving.

PR checks may be needed for users that do not use common IDE that has chosen formatter support. But for this issue, I would like to focus on:

investigate if there are any other tools (except Prettier).
identify 2~3 top ones and try them out. List Pros vs Cons.
choose one to use in the project and identify the workflow
define default formater file and check in the repo
update the documentation with details

Thanks @yinggzz for your work so far. I hope the above description clarifies the goal and scope of this task. If you have any question, please let us know.

Hi @llxia , thank you for your instruction! After a lot of research, I couldn’t really find other tools that are similar to Prettier and support integration with different IDEs and languages.
Please see below for my research on Prettier, it can be used as a pre-commit tool to format file before committing.
I was wondering if you can elaborate what to include in the “Format file” besides links for downloading it for different code editors.

Prettier
pros:

as contributors for open sources are dispersed or new to the project, with Prettier, individuals not familiar with the style guidelines don’t have to worry when making a pull request
owners, maintainers, collaborators don’t have to enforce a style guide in code reviews
consistent code formatting across entire codebase
Installing and using Prettier in a project is generally a straightforward process, and Prettier’s documentation is exemplary.

Cons:

some styling/markup/programming languages not supported, for a list of languages it supports, see: https://prettier.io/docs/en/

Pull-requests, pre-commit hook

Each contributor to the project can write own styled code, Prettier will format it before anyone code review it. When changes are committed, files in the commit will automatically be formatted.
You can use Prettier with a pre-commit tool. This can re-format your files that are marked as “staged” via git add before you commit.
There are many options to achieve this: https://prettier.io/docs/en/precommit.html
Prettier pre-commit hook set-up: https://sia.codes/posts/how-to-add-prettier-to-a-project/

Example use case for a project: Run prettier on a large code base at once https://flexport.engineering/upgrading-prettier-on-a-large-codebase-28d56c4de49e
Goal: run prettier so that changes it makes are attributed correctly in git, no merge conflict in open pull requests, repeatable.

develop a small set of scripts to install and upgrade prettier
run it on every file in code base, clean up errors, make commit to master and update all open pull request
*scripts should be run without anyone else committing to master before the scripts finish.

General work flow to automate code formatting in pull requests:
https://peterevans.dev/posts/github-actions-how-to-automate-code-formatting-in-pull-requests/

When a pull request is raised the workflow executes as a check.
The code formatter executes and modifies files if necessary.
The workflow checks to see if any tracked files by git have been modified.
If modified files exist they are committed and pushed to the remote.
When using a repo scoped Personal Access Token instead of GITHUB_TOKEN, the push triggers all pull request checks to run again.

Add prettier in TRSS https://github.com/adoptium/aqa-test-tools/pull/611

https://github.com/adoptium/aqa-test-tools/pull/612
https://github.com/adoptium/aqa-test-tools/pull/613

Code formatter prettier is added in TRSS. I will close this PR for now.


Bug in PartialTomoObjFuncEval with regards to n-qubits for qalloc() call

Take the following test of QITE
TEST(QiteWorkflowTester, checkDeuteronH2) {
  using namespace qcor;
  xacc::set_verbose(true);
  auto compiler = xacc::getCompiler("xasm");
  auto ir = compiler->compile(R"(__qpu__ void f(qbit q) { X(q[0]); })", nullptr);
  auto x = ir->getComposite("f");

  auto observable = -2.1433 * X(0) * X(1) - 2.1433 * Y(0) * Y(1) +
                    .21829 * Z(0) - 6.125 * Z(1) + 5.907;
  xacc::internal_compiler::qpu = xacc::getAccelerator("qpp");
  const int nbSteps = 25;
  const double stepSize = 0.1;
  auto problemModel = QuaSiMo::ModelFactory::createModel(x, &observable);
  auto workflow = QuaSiMo::getWorkflow(
      "qite", {{"steps", nbSteps}, {"step-size", stepSize}});
  auto result = workflow->execute(problemModel);
  const auto energy = result.get<double>("energy");
}

This is a 2 qubit problem, but at first PartialTomoObjFuncEval will be evaluating with the state preparation circuit which is on 1 qubit, and it tries to qalloc() with statePrep->nPhysicalBits(). This causes an error in the backend qpp accelerator due to mismatched n-qubits in the provided buffer vs the composite instruction being executed.
Maybe we need to update evaluate() to also take the number of qubits.

a quick hack to get this working would be adding an identity gate
  auto ir = compiler->compile(R"(__qpu__ void f(qbit q) { X(q[0]); I(q[1]); })", nullptr);

I think this is a bug, it should do
auto tmp_buffer = qalloc(target_operator->nBits());

oh cool. I'll update with my next commit.


Update: Microsoft.DotNetWorkload.Ios version 14.4.100-preview.3.1326

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[ ] Have you tested your manifest locally with winget install --manifest <path>?
[X] Does your manifest conform to the 1.0 schema?

Microsoft Reviewers: Open in CodeFlow

@wingetbot waivers Add Validation-Domain

@wingetbot waivers Add Validation-Domain

@wingetbot waivers Add Validation-Domain

@wingetbot waivers Add Validation-Domain


Tuple generates a compiler error

This gives a proper error message, saying * unsupported type: [number, number] 0x2000 *
let x: [number, number];
x = [10, 10];

However, when written like so:
let x: [number, number] = [10,10]

we get a * Cannot read property 'flags' of null*
(compiler error)

We should spit out a better error message.


Layout are not resizing when hides all panels on the right side

Release Type: Both
Version:  All
Platform(s): Windows
Describe the bug
When you hide all the panels on the right side the layout are not resizing properly.
To Reproduce
Steps to reproduce the behavior:

Open a project in Game Studio
Hide all panels on the right side

Expected behavior
The main scene need to resize.
Screenshots

Log and callstacks
Not applicable
Additional context
Not applicable
**Please assign to me.

Will be necessary to change default editor layout of DockingManager so do i need know if has any away to update the config file for xenko old installations?

It's resolved with PR #192.


[dv, verilator] Fake SRAM device for chip level simulations

This change set implements a small memory used for chip level
simulations. An empty space in the chip address map can be used for this
memory. It is primarily used for the embedded CPU in the design (Ibex)
to signal information to the testbench, for example indicate when the SW
is done and the simulation can exit.
Currently, a couple of addresses in our on-device SRAM are being used
for this purpose. With this patch, those are completely gone.
The simulation SRAM intercepts a TL interface to instantiate a 1:2
socket and the (adapter + ) SRAM. This must NOT exist during synthesis,
hence takes the following strategy:

An interception point is created in rv_core_ibex - this is done by
disconnecting the output of the TL fifo and the module port. This
disconnection happens only if VERILATOR or UVM is defined.
THis allows the user to instantiate the SRAM in the testbench and
connect its inputs and outptuts to the interception point in
rv_core_ibex.
This enables us to preserve the original design hierarchy without
pulluting with simulation components (or adding forces which is not
supported in Verilator).

Please see sim_sram documentation for more details.
Once approved, the address locations for signaling the end of test and
logging will be switched over to use this address space.
Signed-off-by: Srikrishna Iyer<EMAIL_ADDRESS>

@sriyerg
can we just use some unmapped addresses to signal information without adding this SRAM? It will return d_error=1, then let SW check this error and move on without processing this error as it's expected. In this case, we can achieve the same thing but don't need to hack the design

@sriyerg
can we just use some unmapped addresses to signal information without adding this SRAM? It will return d_error=1, then let SW check this error and move on without processing this error as it's expected. In this case, we can achieve the same thing but don't need to hack the design

It will cause frequent context switch to the exception handler (and back to the main program) every time these writes occur, which may slow down the simulation. Plus, we will have tests that actually need to verify that an exception occurred, so it may be difficult to distinguish whether it occurred due to these write or due to the logic we are actually testing.

@sriyerg
can we just use some unmapped addresses to signal information without adding this SRAM? It will return d_error=1, then let SW check this error and move on without processing this error as it's expected. In this case, we can achieve the same thing but don't need to hack the design

It will cause frequent context switch to the exception handler (and back to the main program) every time these writes occur, which may slow down the simulation.

certainly not a good choice if we have to enter exception routine every time we display debug info. I'm not sure if it's easy to change SW to check the d_error but skip entering exception routine. @gkelly

Plus, we will have tests that actually need to verify that an exception occurred, so it may be difficult to distinguish whether it occurred due to these write or due to the logic we are actually testing.

Current "fake sram" approach has a similar problem when we verify unmapped address as it won't return d_error=1 for those addresses we choose for displaying info.

@sriyerg
can we just use some unmapped addresses to signal information without adding this SRAM? It will return d_error=1, then let SW check this error and move on without processing this error as it's expected. In this case, we can achieve the same thing but don't need to hack the design

It will cause frequent context switch to the exception handler (and back to the main program) every time these writes occur, which may slow down the simulation.

certainly not a good choice if we have to enter exception routine every time we display debug info. I'm not sure if it's easy to change SW to check the d_error but skip entering exception routine. @gkelly

Plus, we will have tests that actually need to verify that an exception occurred, so it may be difficult to distinguish whether it occurred due to these write or due to the logic we are actually testing.

Current "fake sram" approach has a similar problem when we verify unmapped address as it won't return d_error=1 for those addresses we choose for displaying info.

Good point - we should not connect the fake sram if we are stubbing out the CPU - fixed. If we don't stub the CPU, there should be no need to verify unmapped address space using SW tests since our common SV test seq handles it in stubbed cpu mode.

@sriyerg
can we just use some unmapped addresses to signal information without adding this SRAM? It will return d_error=1, then let SW check this error and move on without processing this error as it's expected. In this case, we can achieve the same thing but don't need to hack the design

It will cause frequent context switch to the exception handler (and back to the main program) every time these writes occur, which may slow down the simulation.

certainly not a good choice if we have to enter exception routine every time we display debug info. I'm not sure if it's easy to change SW to check the d_error but skip entering exception routine. @gkelly

Plus, we will have tests that actually need to verify that an exception occurred, so it may be difficult to distinguish whether it occurred due to these write or due to the logic we are actually testing.

Current "fake sram" approach has a similar problem when we verify unmapped address as it won't return d_error=1 for those addresses we choose for displaying info.

Good point - we should not connect the fake sram if we are stubbing out the CPU - fixed. If we don't stub the CPU, there should be no need to verify unmapped address space using SW tests since our common SV test seq handles it in stubbed cpu mode.

I made another change to use forces in DV instead of making the disconnection (which is done only for Verilator since it does not support forces).

well i think if you don't plan on using the tlul link from memory back to
host (am i understanding that right?) then the sim_sram could really just
snoop the tlul bus without having to intercept right?
Then from software perspective they could still define a region, but you at
least won't be impacted by scrambling anymore, and it won't really matter
if someone over-writes that region.
I think this isn't too different from an approach you made before about
just looking at the bus lines.
On Thu, Oct 8, 2020 at 8:56 PM sriyerg<EMAIL_ADDRESS>wrote:

@sriyerg commented on this pull request.
In hw/ip/rv_core_ibex/rtl/rv_core_ibex.sv
https://github.com/lowRISC/opentitan/pull/3684#discussion_r502176082:

 .spare_req_i (1'b0),

 .spare_req_o (),
 .spare_rsp_i (1'b0),
 .spare_rsp_o ());

//
// Interception point for connecting simulation SRAM by disconnecting the tl_d output. The
// disconnection is done only if SYNTHESIS is NOT defined AND RV_CORE_IBEX_SIM_SRAM is
// defined.
//
+`ifdef RV_CORE_IBEX_SIM_SRAM

Mostly no, because i think it will hamper the portability. How would the
mirror approach work?
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/pull/3684#discussion_r502176082,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSSXYUVXTY7GKNNQBBTSJ2CYVANCNFSM4SEEBECA
.

well i think if you don't plan on using the tlul link from memory back to host (am i understanding that right?) then the sim_sram could really just snoop the tlul bus without having to intercept right? Then from software perspective they could still define a region, but you at least won't be impacted by scrambling anymore, and it won't really matter if someone over-writes that region. I think this isn't too different from an approach you made before about just looking at the bus lines.

Yeah, that is exactly how it currently is. The problem is, we do need to define that region in the linker script so that it does not end up coinciding with the stack. I thought the SW team wanted to have all that cleaned up.

well i think if you don't plan on using the tlul link from memory back to host (am i understanding that right?) then the sim_sram could really just snoop the tlul bus without having to intercept right? Then from software perspective they could still define a region, but you at least won't be impacted by scrambling anymore, and it won't really matter if someone over-writes that region. I think this isn't too different from an approach you made before about just looking at the bus lines.

Yeah, that is exactly how it currently is. The problem is, we do need to define that region in the linker script so that it does not end up coinciding with the stack. I thought the SW team wanted to have all that cleaned up.

yeah good point. Maybe I misunderstood the goals. I thought they were okay with the region, but the issue was scrambling and boot ROM wiping the region.
I think the "snooping" I'm talking about only helps with scrambling. I just realized you'd still have issues with bootROM wiping, since all those transactions would still head towards this region and cause your setup to pick it up. (Unless you want to "trigger a start" based on a specific value :) ).
Anyways, if the goal is to get rid of the region completely from software perspective, then I think you're right, intercept is probably the only way.  I just wonder if we can get away with hardwiring in the design and just forcing in DV (especially for the response port), but maybe that's too much.

well i think if you don't plan on using the tlul link from memory back to host (am i understanding that right?) then the sim_sram could really just snoop the tlul bus without having to intercept right? Then from software perspective they could still define a region, but you at least won't be impacted by scrambling anymore, and it won't really matter if someone over-writes that region. I think this isn't too different from an approach you made before about just looking at the bus lines.

Yeah, that is exactly how it currently is. The problem is, we do need to define that region in the linker script so that it does not end up coinciding with the stack. I thought the SW team wanted to have all that cleaned up.

yeah good point. Maybe I misunderstood the goals. I thought they were okay with the region, but the issue was scrambling and boot ROM wiping the region.
I think the "snooping" I'm talking about only helps with scrambling. I just realized you'd still have issues with bootROM wiping, since all those transactions would still head towards this region and cause your setup to pick it up. (Unless you want to "trigger a start" based on a specific value :) ).

Yeah, right BootROM wiping that region is a potential problem. The SW test status monitoring logic is probably ok, but it could throw the logger out of whack.

Anyways, if the goal is to get rid of the region completely from software perspective, then I think you're right, intercept is probably the only way. I just wonder if we can get away with hardwiring in the design and just forcing in DV (especially for the response port), but maybe that's too much.

Ha! I went through everything you are pointing out. My originally envisioned using forces. But turns out Verilator does not support the force keyword. See DV setup - it is indeed using forces. The RV_CORE_IBEX_SIM_SRAM define is set only in  the Verilator setup.

Just so it's stated here for the avoidance of doubt: I do not want there to be special addresses in ram_main which cause effects in the simulator. I want any simulator-specific areas to be outside of main ram, so writes to them are clearly distinct from writes to main (or retention) ram. This means that Mask ROM can treat ram_main exactly as it would on the taped-out chip.
My understanding is we cannot use an arbritary unassigned address for writing out simulator information, as we'll end up getting bus errors, which in DV is a hard failure, so we need some kind of receiver device on the bus to intercept the simulator control reads/writes. My original proposal was a peripheral, which could have a well defined interface of memory-mapped registers (avoiding having to intercept RAM writes, instead you get the signals you need), but this "simulator-only" RAM approach means we don't have to make a whole new peripheral, we can do what we need with the pieces we have.
My understanding is that DV is not using their simulator-only area for any stateful values, so I'm not sure the ram primitive even needs to be instantiated fully, we just need to ensure the bus errors don't happen when we write to the sw_test_status address or the sw_logger address, right?

well i think if you don't plan on using the tlul link from memory back to host (am i understanding that right?) then the sim_sram could really just snoop the tlul bus without having to intercept right? Then from software perspective they could still define a region, but you at least won't be impacted by scrambling anymore, and it won't really matter if someone over-writes that region. I think this isn't too different from an approach you made before about just looking at the bus lines.

Yeah, that is exactly how it currently is. The problem is, we do need to define that region in the linker script so that it does not end up coinciding with the stack. I thought the SW team wanted to have all that cleaned up.

yeah good point. Maybe I misunderstood the goals. I thought they were okay with the region, but the issue was scrambling and boot ROM wiping the region.
I think the "snooping" I'm talking about only helps with scrambling. I just realized you'd still have issues with bootROM wiping, since all those transactions would still head towards this region and cause your setup to pick it up. (Unless you want to "trigger a start" based on a specific value :) ).

Yeah, right BootROM wiping that region is a potential problem. The SW test status monitoring logic is probably ok, but it could throw the logger out of whack.

Anyways, if the goal is to get rid of the region completely from software perspective, then I think you're right, intercept is probably the only way. I just wonder if we can get away with hardwiring in the design and just forcing in DV (especially for the response port), but maybe that's too much.

Ha! I went through everything you are pointing out. I originally envisioned using forces. But turns out Verilator does not support the force keyword. See DV setup - it is indeed using forces. The RV_CORE_IBEX_SIM_SRAM define is set only in the Verilator setup.

o really? o that sucks.... well then this definitely is the way to go and LGTM :)

Just so it's stated here for the avoidance of doubt: I do not want there to be special addresses in ram_main which cause effects in the simulator. I want any simulator-specific areas to be outside of main ram, so writes to them are clearly distinct from writes to main (or retention) ram. This means that Mask ROM can treat ram_main exactly as it would on the taped-out chip.
My understanding is we cannot use an arbritary unassigned address for writing out simulator information, as we'll end up getting bus errors, which in DV is a hard failure, so we need some kind of receiver device on the bus to intercept the simulator control reads/writes. My original proposal was a peripheral, which could have a well defined interface of memory-mapped registers (avoiding having to intercept RAM writes, instead you get the signals you need), but this "simulator-only" RAM approach means we don't have to make a whole new peripheral, we can do what we need with the pieces we have.
My understanding is that DV is not using their simulator-only area for any stateful values, so I'm not sure the ram primitive even needs to be instantiated fully, we just need to ensure the bus errors don't happen when we write to the sw_test_status address or the sw_logger address, right?

Yes I think everything you said is true. I was originally hoping we could do this without the intercept ifdef... but without the intercept you would need a valid address (even if this address isn't going to be physically used).  DV would also still get confused on ROM wiping (or really any kind of policy based memory wiping).

Just so it's stated here for the avoidance of doubt: I do not want there to be special addresses in ram_main which cause effects in the simulator. I want any simulator-specific areas to be outside of main ram, so writes to them are clearly distinct from writes to main (or retention) ram. This means that Mask ROM can treat ram_main exactly as it would on the taped-out chip.
My understanding is we cannot use an arbritary unassigned address for writing out simulator information, as we'll end up getting bus errors, which in DV is a hard failure, so we need some kind of receiver device on the bus to intercept the simulator control reads/writes. My original proposal was a peripheral, which could have a well defined interface of memory-mapped registers (avoiding having to intercept RAM writes, instead you get the signals you need), but this "simulator-only" RAM approach means we don't have to make a whole new peripheral, we can do what we need with the pieces we have.
My understanding is that DV is not using their simulator-only area for any stateful values, so I'm not sure the ram primitive even needs to be instantiated fully, we just need to ensure the bus errors don't happen when we write to the sw_test_status address or the sw_logger address, right?

Thanks for the clarification, @lenary. The RAM primitive is added in case we ever need the SW test to read runtime data from the testbench. We will avoid it as much as possible, but it doesn't hurt to have it. It is already disabled by default via a parameter.

well i think if you don't plan on using the tlul link from memory back to host (am i understanding that right?) then the sim_sram could really just snoop the tlul bus without having to intercept right? Then from software perspective they could still define a region, but you at least won't be impacted by scrambling anymore, and it won't really matter if someone over-writes that region. I think this isn't too different from an approach you made before about just looking at the bus lines.

Yeah, that is exactly how it currently is. The problem is, we do need to define that region in the linker script so that it does not end up coinciding with the stack. I thought the SW team wanted to have all that cleaned up.

yeah good point. Maybe I misunderstood the goals. I thought they were okay with the region, but the issue was scrambling and boot ROM wiping the region.
I think the "snooping" I'm talking about only helps with scrambling. I just realized you'd still have issues with bootROM wiping, since all those transactions would still head towards this region and cause your setup to pick it up. (Unless you want to "trigger a start" based on a specific value :) ).

Yeah, right BootROM wiping that region is a potential problem. The SW test status monitoring logic is probably ok, but it could throw the logger out of whack.

Anyways, if the goal is to get rid of the region completely from software perspective, then I think you're right, intercept is probably the only way. I just wonder if we can get away with hardwiring in the design and just forcing in DV (especially for the response port), but maybe that's too much.

Ha! I went through everything you are pointing out. I originally envisioned using forces. But turns out Verilator does not support the force keyword. See DV setup - it is indeed using forces. The RV_CORE_IBEX_SIM_SRAM define is set only in the Verilator setup.

o really? o that sucks.... well then this definitely is the way to go and LGTM :)

@imphil
Is there a way Verilator could support forces in a different way (I saw an example online where they tinkered with the Verilated model of the design). If we could do this, then rv_core_ibex need not be touched at all.

Thank you all for your reviews! Merging this in now. More fixes as needed can be made later.


JanusGraph support

Turn off HTTP wire logging. Log files are so big they cant be displayed in Travis CI and are probably making the build slow.
@F2006 Could you add a comment suggesting what may be wrong with the logging configuration? I rebased off the awslabs:travis branch so theoretically it should work the same.
Unless... logging backend changed. checking...

@amcp It seems like the libs was obfuscated and I think this is breaking the log4j configuration, since the packages changed.
E.g:

ElasticSearch package is now o.j.d.es.ElasticSearchIndex
AWS lib package is now o.a.h.impl.execchain.MainClientExec


ISPN-13049 RollingUpgrade should not timeout

https://issues.redhat.com/browse/ISPN-13049

Integrated into master, thanks @gustavonalle !


Configure Envoy tracing for external http traffic

Changes

:gift: Configure Envoy tracing for external http traffic

/kind enhancement
Hello :wave:
It could be very useful to configure Envoy tracing to follow an external HTTP request from the moment when it reaches the gateway to the knative service itself. Until now, we were only able to configure traces starting from the activator service, which is already not bad, but:

not having tracing at the gateway level misses some requests like 4xx or 5xx errors thrown by Envoy
adding tracing here also allow to measure the latency between the gateway and the activator service, and can help troubleshooting

Demo
By configuring the config-kourier configmap like this:
data:
  tracing-enabled: "true"
  tracing-collector-host: "jaeger.tracing.svc.cluster.local"
  tracing-collector-port: "9411"
  tracing-collector-endpoint: "/api/v2/spans"

We were able to get a new kourier-knative span (before the activator-service):

Clicking on the trace gives various details like: the host, the http method, some headers, etc.
In the previous example, we were using Grafana Tempo as the collector, but it should work fine with everything supporting Zipkin.
Release Note
Add tracing support at the gateway level

Docs
WIP, I'll do this once the PR has been reviewed (because things can change in the meantime).

Super awesome! Thank you so much @norbjd I will review this next week (though next Monday is public holiday so might be slow to response).

Overall looks good to me. One question before moving on the detailed review, how do you think about using config-tracing especially zipkin-endpoint and backnd instead of introducing the new fields in config-kourier?
As controller already uses config-logging and config-observability, config-tracing, it makes sense?

I see. Then, let's use config-kourier like you have already done.
With said, can we use one configuration parameter like?
data:
  tracing-collector-endpoint: "jaeger.tracing.svc.cluster.local:9411/api/v2/spans"

Then, parse the edpoint and enable/disable via omit or specified.

/lgtm
/approve
Thank you!


Fix division by zero due to exact off-diagonal zeros in Hessenberg matrix

Closes #267

@mschauer seems like the patch version in project.toml was not the same as the latest tag, so I'm bumping it to 0.8.2 here then and hope tag bot fixes everything for us :D


Server crash when resetting mines:-

Error: Allowed memory size of<PHONE_NUMBER> bytes exhausted (tried to allocate 581632 bytes)
File: MineReset_v3.phar/src/falkirks/minereset/task/ResetTask
Line: 30
Type: E_ERROR

THIS CRASH WAS CAUSED BY A PLUGIN
BAD PLUGIN: MineReset v3

Code:
[21]     /** @var string $ratioData */
[22]     private $ratioData;
[23]     /** @var int $levelId */
[24]     private $levelId;
[25]     /** @var Chunk $chunkClass */
[26]     private $chunkClass;
[27]
[28]     public function __construct(string $name, array $chunks, Vector3 $a, Vector3 $b, array $data, $levelId, $chunkClass){
[29]         $this->name = $name;
[30]         $this->chunks = serialize($chunks);
[31]         $this->a = $a;
[32]         $this->b = $b;
[33]         $this->ratioData = serialize($data);
[34]         $this->levelId = $levelId;
[35]         $this->chunkClass = $chunkClass;
[36]     }
[37]     /**
[38]      * Actions to execute when run
[39]      *
[40]      * @return void

Backtrace:

PocketMine-MP version: 1.7dev #516 [Protocol 160; API 3.0.0-ALPHA10]
Git commit:<PHONE_NUMBER>000000000000000000000000000000
uname -a: Linux ns533426 4.13.0-19-generic #22-Ubuntu SMP Mon Dec 4 11:58:07 UTC 2017 x86_64
PHP Version: 7.2.0
Zend version: 3.2.0
OS : Linux, linux

Perhaps your mine is too large. Does this always happen when you reset a mine? Does it happen with all sizes of mine?

I use /mine reset-all and there are about 30 mines..

But it doesn't crash when running /mine reset on individual mines?

No!


Forced Jump Breaks Checker Pieces

While playing through the game, I would eventually not be able to move any checker pieces for either player at a certain point. I had a feeling that the issue was being caused by the JumpAvailable function of BoardGenerator.cs, so I commented it out so that the function would always return false and it stopped. This function will need to be looked at further to figure out where the problem lies.

Issue has been resolved.


clab config not persistent after redeploy

I noticed after upgrading my clab version from 43.0 to 47.1 that the config is not persistent after a redeploy of the topology.
Test would be, deploy topology for the first time --> make a config change --> destroy lab --> deploy again --> verify if change is persistent.
1 upgrade clab to version 47.1
root@s4qd-pod75:/home/ubuntu/gitlab/srl-dc-fabric-fundamentals-lab# clab version upgrade
A newer containerlab 0.47.1 is available. Release notes: https://containerlab.dev/rn/0.47.1
You are running containerlab 0.43.0 version
Downloading https://github.com/srl-labs/containerlab/releases/download/v0.47.1/containerlab_0.47.1_linux_amd64.deb
Preparing to install containerlab 0.47.1 from package
(Reading database ... 115507 files and directories currently installed.)
Preparing to unpack .../containerlab_0.47.1_linux_amd64.deb ...
Unpacking containerlab (0.47.1) over (0.43.0) ...
Setting up containerlab (0.47.1) ...

                           _                   _       _
                 _        (_)                 | |     | |
 ____ ___  ____ | |_  ____ _ ____   ____  ____| | ____| | _
/ ___) _ \|  _ \|  _)/ _  | |  _ \ / _  )/ ___) |/ _  | || \
( (__| |_|| | | | |_( ( | | | | | ( (/ /| |   | ( ( | | |_) )
\____)___/|_| |_|\___)_||_|_|_| |_|\____)_|   |_|\_||_|____/

    version: 0.47.1
     commit: 1da5ebd2
       date: 2023-10-24T22:09:40Z
     source: https://github.com/srl-labs/containerlab
 rel. notes: https://containerlab.dev/rn/0.47/#0471

2 Start with a fresh deployment by using --reconfgure
root@s4qd-pod75:/home/ubuntu/gitlab/srl-dc-fabric-fundamentals-lab# ll
total 72
drwxr-xr-x  6 root root 4096 Oct 26 09:31 ./
drwxr-xr-x 17 root root 4096 Oct 26 09:22 ../
-rwxr-xr-x  1 root root   37 Oct 26 09:22 00.show_lab.sh*
-rwxr-xr-x  1 root root   36 Oct 26 09:22 01.deploy_srl.sh*
-rwxr-xr-x  1 root root  335 Oct 26 09:22 03.initialize_hosts.sh*
-rwxr-xr-x  1 root root   49 Oct 26 09:22 10.gnmic_example.sh*
-rwxr-xr-x  1 root root   37 Oct 26 09:22 91.destroy_srl.sh*
-rwxr-xr-x  1 root root  310 Oct 26 09:22 98.check_xdp.sh*
-rwxr-xr-x  1 root root  386 Oct 26 09:22 99.repair_xdp.sh*
drwxr-xr-x  7 root root 4096 Oct 26 09:31 clab-lab/
drwxr-xr-x 10 root root 4096 Oct 26 09:22 config/
drwxr-xr-x  8 root root 4096 Oct 26 09:22 .git/
-rw-r--r--  1 root root   10 Oct 26 09:22 .gitignore
-rw-r--r--  1 root root 1025 Oct 26 09:22 gnmic_subscription.yaml
drwxr-xr-x  2 root root 4096 Oct 26 09:22 img/
-rw-r--r--  1 root root 1192 Oct 26 09:22 README.md
-rw-r--r--  1 root root 1413 Oct 26 09:30 topology.yml
-rw-r--r--  1 root root 1413 Oct 26 09:36 .topology.yml.bak
root@s4qd-pod75:/home/ubuntu/gitlab/srl-dc-fabric-fundamentals-lab# clab dep -t topology.yml --reconfigure
INFO[0000] Containerlab v0.47.1 started
INFO[0000] Parsing & checking topology file: topology.yml
INFO[0000] Removing /home/ubuntu/gitlab/srl-dc-fabric-fundamentals-lab/clab-lab directory...
INFO[0000] Creating lab directory: /home/ubuntu/gitlab/srl-dc-fabric-fundamentals-lab/clab-lab
INFO[0000] Creating container: "host11"
INFO[0000] Creating container: "host10"
INFO[0000] Creating container: "host12"
INFO[0000] Creating container: "host20"
INFO[0000] Creating container: "dc-leaf-1"
INFO[0000] Creating container: "dc-spine-2"
INFO[0000] Creating container: "dc-spine-1"
INFO[0000] Creating container: "dc-leaf-2"
INFO[0002] Creating link: dc-spine-1:e1-2 <--> dc-leaf-2:e1-1
INFO[0003] Creating link: dc-spine-2:e1-2 <--> dc-leaf-2:e1-2
INFO[0003] Creating link: dc-spine-1:e1-1 <--> dc-leaf-1:e1-1
INFO[0003] Creating link: host20:eth1 <--> dc-leaf-2:e1-10
INFO[0004] Creating link: dc-spine-2:e1-1 <--> dc-leaf-1:e1-2
INFO[0004] Creating link: host10:eth1 <--> dc-leaf-1:e1-10
INFO[0004] Creating link: host11:eth1 <--> dc-leaf-1:e1-11
INFO[0004] Creating link: host12:eth1 <--> dc-leaf-1:e1-12
INFO[0005] Running postdeploy actions for Nokia SR Linux 'dc-spine-2' node
INFO[0005] Running postdeploy actions for Nokia SR Linux 'dc-leaf-2' node
INFO[0005] Running postdeploy actions for Nokia SR Linux 'dc-leaf-1' node
INFO[0005] Running postdeploy actions for Nokia SR Linux 'dc-spine-1' node
INFO[0023] Adding containerlab host entries to /etc/hosts file
INFO[0023] Adding ssh config for containerlab nodes
+---+---------------------+--------------+-------------------------------+-------+---------+-----------------+----------------------+
| # |        Name         | Container ID |             Image             | Kind  |  State  |  IPv4 Address   |     IPv6 Address     |
+---+---------------------+--------------+-------------------------------+-------+---------+-----------------+----------------------+
| 1 | clab-lab-dc-leaf-1  | e3236ca45408 | ghcr.io/nokia/srlinux:23.7.1  | srl   | running | <IP_ADDRESS>/24 | 2001:172:20:20::b/64 |
| 2 | clab-lab-dc-leaf-2  | be9c94e81822 | ghcr.io/nokia/srlinux:23.7.1  | srl   | running | <IP_ADDRESS>/24  | 2001:172:20:20::5/64 |
| 3 | clab-lab-dc-spine-1 | ca2ba3def795 | ghcr.io/nokia/srlinux:23.7.1  | srl   | running | <IP_ADDRESS>/24  | 2001:172:20:20::7/64 |
| 4 | clab-lab-dc-spine-2 | 930b7ef359f4 | ghcr.io/nokia/srlinux:23.7.1  | srl   | running | <IP_ADDRESS>/24  | 2001:172:20:20::9/64 |
| 5 | clab-lab-host10     | 7eb4169c5d66 | pklepikov/ubuntu-tools:latest | linux | running | <IP_ADDRESS>/24  | 2001:172:20:20::6/64 |
| 6 | clab-lab-host11     | e36457b5060d | pklepikov/ubuntu-tools:latest | linux | running | <IP_ADDRESS>/24  | 2001:172:20:20::8/64 |
| 7 | clab-lab-host12     | dd238582526d | pklepikov/ubuntu-tools:latest | linux | running | <IP_ADDRESS>/24 | 2001:172:20:20::a/64 |
| 8 | clab-lab-host20     | c9e74db564c3 | pklepikov/ubuntu-tools:latest | linux | running | <IP_ADDRESS>/24 | 2001:172:20:20::c/64 |
+---+---------------------+--------------+-------------------------------+-------+---------+-----------------+----------------------+

3 Log into the node. Make a change, commit and save config. (add default network-instance with a description)
root@s4qd-pod75:/home/ubuntu/gitlab/srl-dc-fabric-fundamentals-lab# ssh admin@clab-lab-dc-leaf-1
Warning: Permanently added 'clab-lab-dc-leaf-1' (ED25519) to the list of known hosts.
admin@clab-lab-dc-leaf-1's password:
Using configuration file(s): []
Welcome to the srlinux CLI.
Type 'help' (and press <ENTER>) if you need any help using this.
--{ [OLD STARTUP] + running }--[  ]--
A:dc-leaf-1# enter candidate
--{ [OLD STARTUP] + candidate shared default }--[  ]--
A:dc-leaf-1# network-instance default description test
--{ [OLD STARTUP] +* candidate shared default }--[  ]--
A:dc-leaf-1# commit now
All changes have been committed. Leaving candidate mode.
--{ [OLD STARTUP] + running }--[  ]--
A:dc-leaf-1# save startup
/system:
    Saved current running configuration as initial (startup) configuration '/etc/opt/srlinux/config.json'

--{ [OLD STARTUP] running }--[  ]--
A:dc-leaf-1#
EOF encountered

Connection to clab-lab-dc-leaf-1 closed.

4 Destroy topology
root@s4qd-pod75:/home/ubuntu/gitlab/srl-dc-fabric-fundamentals-lab# clab des -t topology.yml
INFO[0000] Parsing & checking topology file: topology.yml
INFO[0000] Destroying lab: lab
INFO[0001] Removed container: clab-lab-host11
INFO[0001] Removed container: clab-lab-host20
INFO[0002] Removed container: clab-lab-host12
INFO[0002] Removed container: clab-lab-host10
INFO[0002] Removed container: clab-lab-dc-leaf-2
INFO[0003] Removed container: clab-lab-dc-leaf-1
INFO[0003] Removed container: clab-lab-dc-spine-1
INFO[0003] Removed container: clab-lab-dc-spine-2
INFO[0003] Removing containerlab host entries from /etc/hosts file
INFO[0003] Removing ssh config for containerlab nodes
root@s4qd-pod75:

5 Deploy again. Note that the project directory, clab-lab,  is being created again
root@s4qd-pod75:/home/ubuntu/gitlab/srl-dc-fabric-fundamentals-lab# clab dep -t topology.yml
INFO[0000] Containerlab v0.47.1 started
INFO[0000] Parsing & checking topology file: topology.yml
INFO[0000] Creating lab directory: /home/ubuntu/gitlab/srl-dc-fabric-fundamentals-lab/clab-lab
INFO[0000] Creating container: "host20"
INFO[0000] Creating container: "host12"
INFO[0000] Creating container: "host10"
INFO[0000] Creating container: "host11"
INFO[0000] Creating container: "dc-spine-1"
INFO[0000] Creating container: "dc-leaf-1"
INFO[0000] Creating container: "dc-leaf-2"
INFO[0000] Creating container: "dc-spine-2"
INFO[0002] Creating link: dc-spine-2:e1-2 <--> dc-leaf-2:e1-2
INFO[0002] Creating link: dc-spine-1:e1-2 <--> dc-leaf-2:e1-1
INFO[0003] Creating link: host20:eth1 <--> dc-leaf-2:e1-10
INFO[0003] Creating link: dc-spine-1:e1-1 <--> dc-leaf-1:e1-1
INFO[0003] Creating link: dc-spine-2:e1-1 <--> dc-leaf-1:e1-2
INFO[0004] Creating link: host11:eth1 <--> dc-leaf-1:e1-11
INFO[0004] Creating link: host10:eth1 <--> dc-leaf-1:e1-10
INFO[0004] Creating link: host12:eth1 <--> dc-leaf-1:e1-12
INFO[0004] Running postdeploy actions for Nokia SR Linux 'dc-leaf-1' node
INFO[0004] Running postdeploy actions for Nokia SR Linux 'dc-spine-1' node
INFO[0004] Running postdeploy actions for Nokia SR Linux 'dc-spine-2' node
INFO[0004] Running postdeploy actions for Nokia SR Linux 'dc-leaf-2' node
INFO[0022] Adding containerlab host entries to /etc/hosts file
INFO[0022] Adding ssh config for containerlab nodes
+---+---------------------+--------------+-------------------------------+-------+---------+-----------------+----------------------+
| # |        Name         | Container ID |             Image             | Kind  |  State  |  IPv4 Address   |     IPv6 Address     |
+---+---------------------+--------------+-------------------------------+-------+---------+-----------------+----------------------+
| 1 | clab-lab-dc-leaf-1  | 1202a5504106 | ghcr.io/nokia/srlinux:23.7.1  | srl   | running | <IP_ADDRESS>/24  | 2001:172:20:20::9/64 |
| 2 | clab-lab-dc-leaf-2  | e26778959c69 | ghcr.io/nokia/srlinux:23.7.1  | srl   | running | <IP_ADDRESS>/24  | 2001:172:20:20::5/64 |
| 3 | clab-lab-dc-spine-1 | 000173c3b88b | ghcr.io/nokia/srlinux:23.7.1  | srl   | running | <IP_ADDRESS>/24  | 2001:172:20:20::7/64 |
| 4 | clab-lab-dc-spine-2 | f565e19ddaf0 | ghcr.io/nokia/srlinux:23.7.1  | srl   | running | <IP_ADDRESS>/24  | 2001:172:20:20::6/64 |
| 5 | clab-lab-host10     | 6f2d1eb5f3de | pklepikov/ubuntu-tools:latest | linux | running | <IP_ADDRESS>/24 | 2001:172:20:20::b/64 |
| 6 | clab-lab-host11     | 56691d463e2b | pklepikov/ubuntu-tools:latest | linux | running | <IP_ADDRESS>/24 | 2001:172:20:20::c/64 |
| 7 | clab-lab-host12     | 2d61abfc36cc | pklepikov/ubuntu-tools:latest | linux | running | <IP_ADDRESS>/24 | 2001:172:20:20::a/64 |
| 8 | clab-lab-host20     | 65db39a49fff | pklepikov/ubuntu-tools:latest | linux | running | <IP_ADDRESS>/24  | 2001:172:20:20::8/64 |
+---+---------------------+--------------+-------------------------------+-------+---------+-----------------+----------------------+

6 Verify is config change is persistent after redeployment. (default network-instance is not configured)
root@s4qd-pod75:/home/ubuntu/gitlab/srl-dc-fabric-fundamentals-lab# ssh admin@clab-lab-dc-leaf-1
Warning: Permanently added 'clab-lab-dc-leaf-1' (ED25519) to the list of known hosts.
admin@clab-lab-dc-leaf-1's password:
Using configuration file(s): []
Welcome to the srlinux CLI.
Type 'help' (and press <ENTER>) if you need any help using this.
--{ [OLD STARTUP] + running }--[  ]--
A:dc-leaf-1# show network-instance summary
+-----------------------------------------------+------------------------+------------------------+------------------------+-----------------------------------------------+----------------------------------------------------------+
|                     Name                      |          Type          |      Admin state       |       Oper state       |                   Router id                   |                       Description                        |
+===============================================+========================+========================+========================+===============================================+==========================================================+
| mgmt                                          | ip-vrf                 | enable                 | up                     |                                               | Management network instance                              |
+-----------------------------------------------+------------------------+------------------------+------------------------+-----------------------------------------------+----------------------------------------------------------+

I can not confirm this. The message Creating lab directory: ... is expected, we call the os.MakeAll functions, that takes a path and creates all the dirs along the path that do not exist, like mkdir with the -p option. So if the path towards the lab folder is there it is basically a noop.
Deploy:
~/projects/containerlab4$ sudo clab deploy -t lab-examples/srl01/
INFO[0000] Containerlab v0.47.2 started
INFO[0000] Parsing & checking topology file: srl01.clab.yml
INFO[0000] Creating docker network: Name="clab", IPv4Subnet="<IP_ADDRESS>/24", IPv6Subnet="2001:172:20:20::/64", MTU='ל'
INFO[0000] Creating lab directory: /home/steiler/projects/containerlab4/clab-srl01
INFO[0000] Creating container: "srl"
INFO[0001] Running postdeploy actions for Nokia SR Linux 'srl' node
INFO[0022] Adding containerlab host entries to /etc/hosts file
INFO[0022] Adding ssh config for containerlab nodes
+---+----------------+--------------+-----------------------+------+---------+----------------+----------------------+
| # |      Name      | Container ID |         Image         | Kind |  State  |  IPv4 Address  |     IPv6 Address     |
+---+----------------+--------------+-----------------------+------+---------+----------------+----------------------+
| 1 | clab-srl01-srl | af0a98f1c3b0 | ghcr.io/nokia/srlinux | srl  | running | <IP_ADDRESS>/24 | 2001:172:20:20::2/64 |
+---+----------------+--------------+-----------------------+------+---------+----------------+----------------------+

Configure:
steiler@vbox:~/projects/containerlab4$ ssh clab-srl01-srl
Warning: Permanently added 'clab-srl01-srl' (ED25519) to the list of known hosts.
................................................................
:                  Welcome to Nokia SR Linux!                  :
:              Open Network OS for the NetOps era.             :
:                                                              :
:    This is a freely distributed official container image.    :
:                      Use it - Share it                       :
:                                                              :
: Get started: https://learn.srlinux.dev                       :
: Container:   https://go.srlinux.dev/container-image          :
: Docs:        https://doc.srlinux.dev/22-11                   :
: Rel. notes:  https://doc.srlinux.dev/rn22-11-1               :
: YANG:        https://yang.srlinux.dev/release/v22.11.1       :
: Discord:     https://go.srlinux.dev/discord                  :
: Contact:     https://go.srlinux.dev/contact-sales            :
................................................................

Using configuration file(s): []
Welcome to the srlinux CLI.
Type 'help' (and press <ENTER>) if you need any help using this.
--{ running }--[  ]--
A:srl# enter candidate
--{ candidate shared default }--[  ]--
A:srl# set network-instance default description "my funny description"
--{ * candidate shared default }--[  ]--
A:srl# set network-instance default admin-state enable
--{ * candidate shared default }--[  ]--
A:srl# commit now save
/system:
    Saved current running configuration as initial (startup) configuration '/etc/opt/srlinux/config.json'

All changes have been committed. Leaving candidate mode.
--{ running }--[  ]--
A:srl# quit
Connection to clab-srl01-srl closed.

Check:
steiler@vbox:~/projects/containerlab4$ grep -B3 -A2 funny clab-srl01/srl/config/config.json
    {
      "name": "default",
      "admin-state": "enable",
      "description": "my funny description"
    },
    {

Destroy:
steiler@vbox:~/projects/containerlab4$ sudo clab destroy -t lab-examples/srl01/
INFO[0000] Parsing & checking topology file: srl01.clab.yml
INFO[0000] Destroying lab: srl01
INFO[0000] Removed container: clab-srl01-srl
INFO[0000] Removing containerlab host entries from /etc/hosts file
INFO[0000] Removing ssh config for containerlab nodes

Redeploy:
steiler@vbox:~/projects/containerlab4$ sudo clab deploy -t lab-examples/srl01/
INFO[0000] Containerlab v0.47.2 started
INFO[0000] Parsing & checking topology file: srl01.clab.yml
INFO[0000] Creating docker network: Name="clab", IPv4Subnet="<IP_ADDRESS>/24", IPv6Subnet="2001:172:20:20::/64", MTU='ל'
INFO[0000] Creating lab directory: /home/steiler/projects/containerlab4/clab-srl01
INFO[0000] Creating container: "srl"
INFO[0000] Running postdeploy actions for Nokia SR Linux 'srl' node
INFO[0016] Adding containerlab host entries to /etc/hosts file
INFO[0016] Adding ssh config for containerlab nodes
+---+----------------+--------------+-----------------------+------+---------+----------------+----------------------+
| # |      Name      | Container ID |         Image         | Kind |  State  |  IPv4 Address  |     IPv6 Address     |
+---+----------------+--------------+-----------------------+------+---------+----------------+----------------------+
| 1 | clab-srl01-srl | 003c92e9f56e | ghcr.io/nokia/srlinux | srl  | running | <IP_ADDRESS>/24 | 2001:172:20:20::2/64 |
+---+----------------+--------------+-----------------------+------+---------+----------------+----------------------+

Check file:
steiler@vbox:~/projects/containerlab4$ grep -B3 -A2 funny clab-srl01/srl/config/config.json
    {
      "name": "default",
      "admin-state": "enable",
      "description": "my funny description"
    },
    {

Check SRL:
steiler@vbox:~/projects/containerlab4$ ssh clab-srl01-srl
Warning: Permanently added 'clab-srl01-srl' (ED25519) to the list of known hosts.
................................................................
:                  Welcome to Nokia SR Linux!                  :
:              Open Network OS for the NetOps era.             :
:                                                              :
:    This is a freely distributed official container image.    :
:                      Use it - Share it                       :
:                                                              :
: Get started: https://learn.srlinux.dev                       :
: Container:   https://go.srlinux.dev/container-image          :
: Docs:        https://doc.srlinux.dev/22-11                   :
: Rel. notes:  https://doc.srlinux.dev/rn22-11-1               :
: YANG:        https://yang.srlinux.dev/release/v22.11.1       :
: Discord:     https://go.srlinux.dev/discord                  :
: Contact:     https://go.srlinux.dev/contact-sales            :
................................................................

Using configuration file(s): []
Welcome to the srlinux CLI.
Type 'help' (and press <ENTER>) if you need any help using this.
--{ running }--[  ]--
A:srl# info from running network-instance default
    network-instance default {
        admin-state enable
        description "my funny description"
    }
--{ running }--[  ]--
A:srl#

So, well... someone else maybe also try this, but I can't reproduce the issue.

I don't know if it makes any difference but I'm using start-up config in the topology file

Hmm @hellt whats our definition of a startup-config?
Is that the if no config already exists startup-config or is it the always and in any case startup-config?

ok, if a config is present in the nodes lab dir we should use that, if not e.g. --reconfigure we should download.
I'll figure out how we do that best

ah, startup-config takes precendence over the local dir @KTodts
The goal of a startup-config is to be the "startup config".
The idea was that our topology should be as declarative as possible, so if we have a startup config in the topo file, this file should be used as a startup config, and thus overriding any config present in the node lab directory.

Although this note here https://containerlab.dev/manual/nodes/#embedded-startup-config says otherwise :D
To be honest, I think we need to then use existing labdir config indeed
/cc @steiler @KTodts

Although this note here https://containerlab.dev/manual/nodes/#embedded-startup-config says otherwise :D
To be honest, I think we need to then use existing labdir config indeed
/cc @steiler @KTodts

This way after installing a project from a repo you have the possibility to build on top of that.

Yes and the note says so... We do have the enforce-startup-config flag otherwise...
This behavior got screwed when I implemented the http(s) download of the config...
Mea culpa. Will fix it!

I just found this issue has been occurred starting from version 0.45.0.
The main issue that I have experienced is even though I have saved my config before destroying the topology, the config is not persistent anymore. After executing deploy command it always copies or uses the config file from startup-config definition in topo-yaml file.,

yes, this is still unresolved.
I will link your internal message to be evaluated when we get to fix this

@hellt  I am having same issue.  I have startup config in  clab lab directory. When I deploy lab again, startup config is not seen.
have you any progress for this bug
thank you


Added icons/readme.md

Closes #145
This Pull Request meets the following criteria:

[ ] Tests have been added/adjusted for my new feature
[ ] New Components are registered in index.js of my project

(btw I would still keep the link to list of icons in the main readme as well)


Don't let zlib dirty its repo on configure

On configure, zlib renames zconf.h to zconf.h.included for no good reason, causing git to report its repo as dirty. The dirty repo then propagates up through cesium-native into whatever projects are using it via submodule, which is really annoying. There are a bunch of issues written for this, along with multiple PRs to fix it in different ways, but seemingly no interest from the maintainers.
So the hacky approach I used here is to simply rename it back after the zlib add_subdirectory. Since the rename was pointless to begin with, this doesn't do any harm and avoids a dirty repo.

Well, my original approach didn't work, because compilers apparently check the current directory for quoted includes before checking anywhere else. So now I've implemented another approach: copy the zlib source into the build dir and let it modify that copy.


Komarov Alexandr YDB (в 00:01 сдал, не бейте, пожалуйста)

Changelog entry
...
Changelog category

New feature
Experimental feature
Improvement
Performance improvement
Bugfix
Backward incompatible change
Documentation (changelog entry is not required)
Not for changelog (changelog entry is not required)

Additional information
...

lgtm


isobasins: Last outlet id sometime one too big and miss last CSV connection

Sometimes, the last id skip one number like in the sequence 1, 2, 3, 4, 6 (no id 5) depending on the chosen size parameter. When it happens, it causes an other issue with the CSV connections file where the last id is missing. This DEM can be used for testing.
Using --size='30'
whitebox_tools.exe -r=Isobasins --dem='dem.flt' --output='isobasins_size30.flt' --size='30' --connections
As expected, the call produces a raster with ids 1,2,3,4,5  but the CSV misses one line for id 5:

UPSTREAM
DOWNSTREAM

1
2

2
3

3
N/A

4
5

Using --size='20'
whitebox_tools.exe -r=Isobasins --dem='dem.flt' --output='isobasins_size20.flt' --size='20' --connections
This time, the call produces a raster with ids 1,2,3,4,5,7 (skips number 6 and uses 7 instead) and the CSV has one line per id, but id 6 is present in the upstream column and id 7 is present in the downstream colum:

UPSTREAM
DOWNSTREAM

1
3

2
3

3
4

4
N/A

5
7

6
N/A

I have just committed a fix for this issue and am now closing.


Uses case let in switch statement

Uses case let in switch statements where appropriate in PreferencesWindowController.swift

Definitely I will move TimeOfDay and City and separate file(s) later on.
I am going to do some straightforward refactoring.
Then less straightforward, but which should lead to removing some lines of code.
My target is to refactor this class before I add some functionality.
And on the go would be nice to refactor file up to state when swiftlint:disable:this file_length linter pragma might be removed.

Awesome, go at it, I'll merge your stuff in the meantime.
If you plan some large scale change that will take you some time, feel free to drop a line in an issue to make sure we can coordinate if needed or if you have any question.


Custom Inline Tags

As far as I can tell, even if a custom tag is inside something like a
 tag, its rendered component won't be rendered inside that parent tag's Text node.
e.g. given this HTML markup

Foo <x-mytag>Bar</x-mytag> Baz

I'd like to render something like this
<Text>Foo <MyTag>Bar</MyTag> Baz</Text>

But instead what i get is this
<Text>Foo</Text>
<MyTag>Bar</MyTag>
<Text>Baz</Text>

Is there any way to achieve this?

Hi, I started working on this issue and I think I have a decent solution.
You'd be able to declare your custom tags like so :
            renderers: {
                mytag: { renderer: myTagRenderer, wrapper: 'Text' }, // new way
                myothertag: myOtherTagRenderer // old regular way (still valid)
            }

If you supply a function, it behaves as it used to. If you use an object, your function must be in the renderer key so you can add other options.
I added the wrapper key, so you can set the wrapper you want for you custom component yourself.
Please note that the wrapper is not a react-native component per-se, it's either "View" or "Text". It's only used by the plugin to make sure views aren't nested inside texts to prevent crashes.
The following renderers behave like this

Please tell me what you think about this solution, and I'll try to add it to the next version.

Sorry for the delayed response @Exilz, I've been off on vacation! I think this is probably the best solution in terms of API design. The only other solution I can think of is checking whether the returned node has an inline prop that's been set to true, but that feels a little too 'magical; to me.


Does not capture errors from reading config file

In GCP composer, adding
[core]
...
dags_are_paused_at_creation = True

seems to cause the following error
Traceback (most recent call last):
  File "/usr/local/bin/airflow", line 7, in <module> exec(compile(f.read(), __file__, 'exec'))
  File "/usr/local/lib/airflow/airflow/bin/airflow", line 21, in <module> from airflow import configuration
  File "/usr/local/lib/airflow/airflow/__init__.py", line 36, in <module> from airflow import settings, configuration as conf
  File "/usr/local/lib/airflow/airflow/settings.py", line 268, in <module> configure_orm()
  File "/usr/local/lib/airflow/airflow/settings.py", line 171, in configure_orm pool_recycle = conf.getint('core', 'SQL_ALCHEMY_POOL_RECYCLE')
  File "/usr/local/lib/airflow/airflow/configuration.py", line 276, in getint return int(self.get(section, key))
ValueError: invalid literal for int() with base 10: '1800\ndags_are_paused_at_creation = True'

that is not being captured by the plugin and reported to Sentry

With the current plugin method, Sentry is run when plugins are imported. I believe that airflow first configures the conf file before importing any plugins. There is a PR against Airflow that will fix this issue https://github.com/apache/airflow/pull/5407.