Restructure & handling of the shakyground grid files

This pull request adds the handling of the shakyground grid files & restructures the existing script
The way to handle the grid files is relativly simple:

We checkout the repo for the grid
We build it locally
We checkout shakyground
And we change the Dockerfile for shakyground, so that we use the image with the grids that we build ourselves.

For the rest, the PR is mainly a bit restructing:

I have a misses_image function, so that I can test easily with docker image inspect if the image is already there (more robust then having a list & grepping for one entry)
I structured the build steps in multiple functions
I added a main function that can be used to run only some parts of the build script (for easier debugging & docker file problem fighting)
I also added a clean function, so that we can test that all the stuff still works without any effects of our previous steps.

I'm sorry that the restructuring is that large, but I hope I'm not the only one who can see that as at least a bit beneficial.
Things still to do (in other pull requests):

Building the tsunami service (currently it has an error that it doesn't find some file that it needs) - and the data of cause.
Building the sysrel service
Preparing our wps server should be done in an init container within the docker compose (similar to https://github.com/riesgos/async/blob/main/wps/init/init_wps.py). I guess this is what I will work on for the next days (in the hope that this PR here is okayish).

Sorry that it took so much time of the day to reach that stage, but my bash-fu is really limited & the problems I had with the shakyground images were super annoying (not super complicated, but error messages after it downloaded the stuff, so it took way to long to try several things out).

By the way, I changed the name of the script, as I think something like ./build.sh assetmaster or ./build all is better then ./build_all.sh assetmaster.
Still it is possible to just run the script without any parameters (./build.sh) and it will do all the build steps.
(Still feels a little bit like writing half of a Makefile - but (I hope) still a little bit better to handle).

Building the tsunami service (currently it has an error that it doesn't find some file that it needs) - and the data of cause.

Building the sysrel service

These are really up to @bpross-52n and @arnevogt - so they shouldn't keep us from merging this.

Preparing our wps server should be done in an init container within the docker compose (similar to https://github.com/riesgos/async/blob/main/wps/init/init_wps.py). I guess this is what I will work on for the next days (in the hope that this PR here is okayish).

Sounds good to me!
For the frontend I'll have a docker-compose file, too, which contains services for middleware, monitor, frontend, and a new version of the frontend. I guess a good part of our work will be in figuring out how to get multiple compose-files to play nicely together - but that's another issue, too.

Unfortunally I can't merge myself (missing permissions). So @MichaelLangbein please merge it today.

One last thing: I did just a little brainstorming regarding shell scripts vs something similar to docker-compose files.
First: I'm not aware if it is actually possible to do all this with docker compose - I just use the subset that I need on a daily basis.
However, if I would introduce configurations similar to the way the docker-compose yml files look like I would endup with a subset like this:
services:
  quakeledger:
    image: "gfzriesgos/quakeledger"
    before_script:
      - "git clone https://github.com/gfzriesgos/quakeledger"
    build:
      context: "quakeledger"
      dockerfile: "metadata/Dockerfile"
      tags:
        - "latest"
    artifacts:
      paths:
        - "metadata/quakeledger.json"
      expose_in: "configs"

  deus:
    image: "gfzriesgos/deus"
    before_script:
      - "git clone https://github.com/gfzriesgos/deus"
    build:
      context: "deus"
      dockerfile: "metadata/Dockerfile"
      tags:
        - "latest"
    artifacts:
      paths:
        - "metadata/deus.json"
        - "metadata/volcanus.json"
        - "metadata/neptunus.json"
      expose_in: "configs"

  shakyground_grid:
    image: "gfzriesgos/shakyground-grid-file"
    before_script:
      - "git clone https://github.com/gfzriesgos/shakyground-grid-file"
    build:
      context: "shakyground-grid-file"
      dockerfile: "Dockerfile"
      tags:
        - "latest"

  shakyground:
    image: "gfzriesgos/shakyground"
    depends_on: shakyground_grid
    before_script:
      - "git clone https://github.com/gfzriesgos/shakyground"
      - "sed -i -e 's/FROM gfzriesgos\/shakyground-grid-file:20211011/FROM gfzriesgos\/skakyground-grid-file:latest/' ./metadata/Dockerfile"
    build:
      context: "shakyground"
      dockerfile: "Dockerfile"
      tags:
        - "latest"
    artifacts:
      paths:
        - "metadata/shakyground.json"
      expose_in: "configs"

While I think this is easier to add/modify for the project partners, I'm not 100% sure if a tool that would be needed to actually do that actions would be reused. (When I currently do something like this, I adjust the dockerfiles - and don't have some before_script, after_script (which I had while brainstorming) or arctifacts.

By the way: I'm not really a fan of yaml - so I would do that only if it would be really beneficial to do.

But if we would go that way overall, we could also set all of that up as an gitlab-ci.yml file too (or maybe similar stuff for the github actions).

While I think this is easier to add/modify for the project partners, I'm not 100% sure if a tool that would be needed to actually do that actions would be reused. (When I currently do something like this, I adjust the dockerfiles - and don't have some before_script, after_script (which I had while brainstorming) or arctifacts.

I think that would be pretty nifty, too!
But my understanding is that docker doesn't want to support before_script functionality - possibly because that would open the door to a lot of unpredictable behavior.


"Siliștea Crucii" is listed in the drop-down menu

Description:
"Siliștea Crucii" is listed in the drop-down menu alongside its corresponding county and commune, according to the law.
Precondition:
The website is up an running.

Step 1
Type "Siliștea Crucii" in the search bar.

Expected results
The location is listed in the drop-down menu as "Comuna Siliștea Crucii, DOLJ".


protoc-gen-go can be installed from a package

I notice that the setup.sh script that sets up Vagrant installs the Go protobug compiler from source. I don't use Vagrant, but this may not be necessary. Ubuntu provides a 'golang-goprotobuf-dev' package that includes  protoc-gen-go.

@bcbrock - I think the issue with using the OS-specific packages is that they may be down level in terms of protocol buffer support.  Not sure about the package you mention, but it might not support PB 3.x

Related to down-level, note that what the script does now is it installs whatever was already coupled to the project via the vendoring mechanism, which is about as precise as you can be.  We would need to be careful about breaking that relationship.

@ghaskins I may have been thinking abut something else. I thought in the past it was quite time consuming to build the protobuf compiler from source. Is that no longer done?

@bcbrock there are two parts:

protoc: this is expensive and performed at baseimage creation (https://github.com/hyperledger/fabric/blob/master/devenv/baseimage/scripts/common/setup.sh#L74)
protoc-gen-go: this is relatively fast, and performed (today) by vagrant-up (https://github.com/hyperledger/fabric/blob/master/devenv/setup.sh#L12)

When you said "protoc-gen-go" I assumed you were referring to the latter, but now I see perhaps you just meant protoc in general.

Sorry, you just said "Go protobuf compiler" which I took to be the protoc-gen-go plugin.  You never said protoc-gen-go explicitly.

I meant to mean whatever was  the time-consuming part of building the environment related to the protobuf compiler. Time was when this was not actually necessary. I have found that there is a lot of stuff in the Vagrant setup that is or was not really necessary.
It would be nice if things like this
git checkout 12fb61b292d7ec4cb14b0d60e58ed5c35adda3b7

were better documented. Is this an actual requirement, or just what happened to be the latest thing that worked at the time the script was written? (Rhetorical question.)

@bcbrock that is a great question about the sha.  I have no idea why it was chosen.
On this topic, I need to cut an s390x docker image for dockerhub.  I should probably respin the entire suite (x86/vagrant and x86/docker) too to reflect the fact that @vpaprots updated the scripts.  While technically true that the x86 side should be a no-op, it seems prudent given that there was a change introduced.
Additionally, protobuf 3.0.0-beta3 was released a few days ago (https://github.com/google/protobuf/tree/v3.0.0-beta-3).
Should I upgrade the base image to this stable tag while I am at it @srderson ?

@ghaskins @srderson I think this issue has served its purpose, please close it if you agree.

Early on, there was no binary available. Initially it just checked out master and built that. Then everyone wound up with different versions and some people saw bugs that others did not see. So the latest at the time was chosen.
If there's a binary available now, I would totally agree that we should just download and use it instead of building from source.


Support cmake install

What

Depends on #4313
Fixes #4207

Support and document use of CMake install.
Minimal example has a switch to use find_package. Not rolling it out to others because it's just not as ergonomic, don't want to advertise it all that much. However, the minimal example is used in the sdk package script to test that install is in order before uploading the package script (runs locally). I manually tested the case of a rerun install depend on an arrow system install.
Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[x] I've included a screenshot or gif (if applicable)
[x] I have tested demo.rerun.io (if applicable)
[x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

PR Build Summary
Docs preview
Examples preview
Recent benchmark results
Wasm size tracking

I assume you tested that it works so

... not on ci though, but I think I know why.


License

Thanks for sharing the audio frequency detection code.
Under what license can it be used?

It's MIT. Thank you for directing my attention to this.


chore(HACBS-1717) New script to setup quay secret

Signed-off-by: Scott Hebert<EMAIL_ADDRESS>% ./setup-quay-push-secret.sh
Please enter the target workspace: [managed-release-team-tenant] temp4
Please enter the service account name: [release-service-account]
Please enter the quay repo URL: [https://quay.io/repository/hacbs-release-tests/shebert-dc-metrocmap]
Please enter your quay robot username: [] scoheb
Please enter your quay robot token: []
Going to create SPIAccessTokenBinding in temp4
spiaccesstokenbinding.appstudio.redhat.com/binding-dockerconfigjson-176186 created
Binding created
Waiting for AwaitingTokenData phase
spiaccesstokenbinding.appstudio.redhat.com/binding-dockerconfigjson-176186 condition met
Upload url: https://spi-oauth-spi-system.apps.scott-test-1717.clusters.stonesoupengineering.com/token/temp4/generated-spi-access-token-rr967
Waiting for Injected phase
spiaccesstokenbinding.appstudio.redhat.com/binding-dockerconfigjson-176186 condition met
Linked secret: robot-account-pull-secret-176186

% oc get sa/release-service-account -n temp3
NAME                      SECRETS   AGE
release-service-account   2         5m40s

% oc get sa/release-service-account -n temp3 -o yaml
apiVersion: v1
imagePullSecrets:
- name: release-service-account-dockercfg-j2c8g
kind: ServiceAccount
metadata:
  annotations:
    spi.appstudio.redhat.com/linked-access-token-binding: binding-dockerconfigjson-176186
  creationTimestamp: "2023-02-10T03:35:58Z"
  labels:
    spi.appstudio.redhat.com/managed-by-binding: binding-dockerconfigjson-176186
  name: release-service-account
  namespace: temp3
  resourceVersion: "13946611"
  uid: f689269b-05f2-4f30-8583-8a48ef89052d
secrets:
- name: release-service-account-dockercfg-j2c8g
- name: robot-account-pull-secret-176186

fixed all comments and made some improvements to variables and error handling


Update to use mkdocstrings-python v1.8+

mkdocstrings-python had a few new releases with very interesting features that would be good to have available in this extension too.
I guess it is probably not doable, but it would be good if this extension could be somehow installed alongside any version of mkdocstring-python, so it is not necessary to catch up to every mkdocstring-python.

This extension actually depends on mkdocstrings-python and extends it by subclassing. The current dependency will work with any version of mkdocstrings-python from 1.6.2 to anything less than 2.0, so what you want should already be supported.
Did you actually try this and it didn't work?

Wooops. No, I think I just got fooled by the project version number and the version number in the pyproject.toml and I missed the >= relation. I just tried it and it works. Sorry for the noise!
I'm having one issue but it is totally unrelated to this, so I will open a different issue.


add consistent task dispatcher

a consistent task dispatcher implemented using consistent hashing

Hi,
I'm quite confuse about the Deployment error "Error: Fetching git information failed". Can someone help me through this? Thank you so much!

We have changed how we add modules. No longer is it a manual PR process. Go to https://deno.land/x and click the "add module button" - follow the instructions. Thanks!


[GSSoC'23] Adding Hovering effect on Arrow Button

Fixes Issue - 1649
Closes #1649

Changes proposed

Screenshots
https://github.com/Spyware007/Animating-Buttons/assets/114330097/91630b69-e885-47ed-a381-27176517e831

Checklist

[x] You've linked this PR to the correct issue.
[x] You have checked that the code is working correctly.
[x] You ⭐ the repository!

Note to reviewers

@Souravvmishra @Spyware007 sir, i have created this pr 3 days ago but no action has done on this pr.
please review this pr and requested to merge it under GSSoC'23 program

@Souravvmishra @Spyware007 sir, please review this pull request as this pr has created last week

@Souravvmishra @Spyware007
I have created this pr 3 weeks ago, but no action has done till now
please review this pull request and requested to merge this pr

@Avdhesh-Varshney Apologies For The Delay. You've done a great work buddy.


aura, babe: remove slot inherent data

Fixes #8029.
ProvideInherent for both Aura and BABE pallets have been removed more than a year ago, I think it's safe to remove the providers now and the rest of the slot inherent code.
polkadot companion: https://github.com/paritytech/polkadot/pull/4973
cumulus companion: https://github.com/paritytech/cumulus/pull/1041

@bkchr I changed the verifiers to ignore the unhandled inherent errors if they are for the babe or aura slot. Do you think this is a reasonable compromise? The blocks that still include the slot inherent are more than a year old by now so I don't think we're losing any security by skipping this check. Otherwise we have to hold on to this code forever.

Do I get it right that "inherent data" means that both the timestamp (and before this change, the slot number) are injected by each node independently and are used by the consensus locally to check other data against them? So these changes affect nothing in synchronization or storage and are therefore backward compatible.

Inherent data is injected by block authors and it gets persisted in the block (like an extrinsic). Additionally, when verifying a block we also create inherent data in order to validate it against the inherent data existing in the block (e.g. for timestamps, the inherent data we generate now should have a higher timestamp than whatever is in the block).


Updated documentation for eventlisteners and fixed missing event/vnode for arrays of handlers

I'm probably OK with this change, but tests are missing.

Thank you for the bugfix and added documentation @kay999 :+1:  This is now part of the most recent release.


[BUG] Fix runtime error using Python 3.8/gunicorn 19.9.0

Describe the bug
There is runtime error/infinite loop when running the latest docker image of building blocks.
To Reproduce
Steps to reproduce the behavior:

Running the latest docker image of building blocks in the develop branch is resulting in a runtime error:

[2020-09-25 20:40:03 +0000] [382] [INFO] Booting worker with pid: 382
/usr/local/lib/python3.8/os.py:1023: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used
  return io.open(fd, *args, **kwargs)

Expected behavior
The building block should run without this runtime warning. This issue has been fixed the latest version gunicorn as mentioned here: https://github.com/benoitc/gunicorn/issues/209 and can be resolved by increasing the gunicorn version to 20.0.4

There is also one another related issue that gevent version needs to be updated. https://github.com/gevent/gevent/issues/1260#issuecomment-697346787
It looks like this is caused since python3-alpine3.11 now points to Python 3.8. Previously this was Python 3.7.


dynamic provisioning for nas ?

any plan for this?

We will add the nas provisioner this month.
The provisioner creates pv, which is one subpath of alibaba cloud nas volume. Not to create one nas volume for each pv.

ok 👍


Draft: add protos and generate code

This PR is a draft for codegen in the Rust SDK: internally Turnkey uses proto3 to define all types and interfaces so it seems like a waste to force our users to manually write types. We can generate it all!
The proto folder now contains the source protos, and src/gen contains generated code. I haven't yet tried to use this with a Rust project hence why this is still a draft PR.

If this is intended to be a general purpose SDK, I'd suggest that accessing environment variables directly (and the use of .env files) should be up to the SDK user, and not baked into the SDK itself. My personal use case is likely to see these values coming from other rust code.
If you really want this for convenience, then env variable access should be optional, ie something like this this:
impl Turnkey {
    pub fn new(base_url: String, stamper: TurnkeyApiKey) -> Self {
        Self {
            base_url,
            stamper,
            client: Client::new(),
        })
    }

    pub fn new_from_env() -> TurnkeyResult<Self>  {
        Self::new(
           base_url: env::var("TURNKEY_BASE_URL")
                .map_err(|e| TurnkeyError::OtherError(e.to_string()))?,
            stamper: TurnkeyApiKey::new_from_env()?,
        )
    }


RFC2136 RecordType Option

As explained in #1456 this PR makes it possible to control whether A, AAAA or both record types are changed when updating using RFC2136.
Tasks

[x] Modify edit page
[x] Modify service function
[x] Modify table overview

Open Questions
pfSense do not changed their table overview template, so you cannot see which record types are updated. Should we add this in OPNsense as it might be useful because you do not have to open the edit page for each update task? (see discussion)

I will try to change the overview of all RFC2136 update tasks!

One should keep it as simple as possible. In order to follow this idea I have added an extra check so only ip address types which should be updated are displayed in the overview table.

And BTW: thanks for working on this 👍

OpenSource: Everyone can use it, but you should also try to give something back! :+1:

@fichtner Updated branch; I will test it now. :checkered_flag:

@fichtner Should be fixed! :)

@fichtner Also added a help text to undestand the new 'all' option.

Ready for review.

Merged, thanks!

Two small follow-ups committed. I think this will land in 17.1.3 next week. Thanks again.


Whitelisting parameters in post/put request

Sorry if this isn't the best place to ask but is there a standard way, or recommended library to support the equivalent of strong parameters from ruby on rails aka a way to whitelist parameters sent to post/put requests to ensure users are only allowed to change specific columns when trying to insert/update data?
I found this library https://github.com/ssowonny/strong-params but it seems like it might not support koa v2 since there's an unresolved pull request that says Update to koa v2.x middleware

That package looks quite unobtrusive - have you tried it? Due to koa-convert in Koa that package should "just work".

Sorry for the late reply, I'll take a look at it. I also found https://github.com/oscaroox/objection-visibility which also might work since i'm using the objectionjs library


Add flag or icons

In Kanban board it is typical to use icons to flag certain cards
would be great to get possibility to flag cards with certain icons like priority, alarm clock, thunder etc.
Maybe Fontawesome isons could be made available via an additional category axis, where the text of the category would pick the ison from Fontawesome.

Or anything from here https://fontawesome.com/v6.0/icons

Having all fontawesome icons in the mod, would be too much I think. And dynamically download files from CDN is restricted to 10k/downloads per month for a free license. Hence adding selected files to the mod package (no issue with the fontawesome open source copyright, because keeping the reference).


Code clean up

@hipertracker do you mind another PR?
Changes:

using xxhash for string hashing instead of Golang internal runtime.memhash (internal functions may not be safe)
using official collator for sorting instead of Tidwall's, this should also slightly improve sorting performance
removed size hints for unique words dictionary: if you don't know how much data you need to store, don't preallocate the space 🤷♂
in the last commit I accidentally used Latin version of words extraction, in this PR I switched back to the proper Unicode one.

This version is a bit slower than the previous one (because of use of Unicode word extraction and no dictionary preallocation), but it is how I would do it, if I am not chasing extreme performance.
Could you also add RAM usage to your benchmark?
Cheers

What is the best way to check RAM usage of the running Golang script? MacOS has a tool Activity Monitor but it can't display anything running less than a second. Golang script with sorting showed up in this tool and used about 50MB.


Remove PostalCodeElement

Summary

In the next major version, we should remove support for the PostalCodeElement as it is no longer the recommended way to collect postal code. Users are suggested to build their own postal code input.

Is there a way I can hide by passing a prop to the element ?

@isuruAb, why not just not render the Element? Can you share a bit more about what you're trying to do?
(If you're looking to hide the postal code field in the combined card Element, you can pass in hidePostalCode=true).

@atty-stripe What is the correct way to determine if we need to collect post code information?

@streamich right now we recommend always collecting it as it helps detect fraud better. That said, we see banks in the US, UK, and Canada frequently implementing postal code checks, so you should at least collect it when the card's billing address is in those countries.

@atty-stripe sorry, to bother you again. The card Stripe element hides/shows the postal code input dynamically depending on the card number. What is that logic? Is it based on country?

How to add postal code to tokenization process if this component is going to be removed?
I mean, there is no way to add extra data to stripe.createToken() without providing element as first argument

@streamich the card Element uses the card number's BIN (first 6 digits) to predict which country it belongs to, but this is error-prone as documented in #20. We recommend specifically asking your users for the billing country, and using that to ask for the postal code.
@SergeyShablenko stripe.createToken accepts the postal code as address_zip. When using react-stripe-elements, the Element is automatically inferred for you, so you can just pass it in as stripe.createToken({ address_zip: '12345' }). See the reference for details: https://stripe.com/docs/stripe-js/reference#stripe-create-token.

Resolved with 346

Has the PostalCodeElement been removed?
If yes can you tell me in which version can I find one?

I think -- in v2.0.3
<EMAIL_ADDRESS>


Added emoji support for Bio

Pre-Submission Checklist

[x] Your pull request targets the staging branch of FreeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/.
[x] You have only one commit.
[x] All new and existing tests pass the command npm run test-challenges.

Type of Change

[x] Breaking change (fix or feature that would change existing functionality)

Checklist:

[x] Tested changes locally.
[x] Closes currently open issue: Closes #10817

When I add emoji to my bio and click the 'Updated from GitHub' button, the emoji appear, but they are bleached out (no colour, hard to make out).

@Bouncey, this is because these are emoji's you imputed on a mobile device.

No no, these are GitHub emoji
🍪 🌵 🐫 🍆 🌍

@Bouncey, weird, I can't reproduce.

@atjonathan Did you update this to account for null bios?

@dhcodes, lol, i forgot. I'll get this sorted soon 😄

@dhcodes, can you reproduce the issue that @Bouncey was having?

@atjonathan I've tried it on two different system (same user, though) and it worked fine except for the null bio issue we discussed in the Contributors room. @Bouncey how did you test it? Your github bio doesn't currently have emojis. Did you delete them?

So, I added cookie, cactus, camel, eggplant and earth_africa to the end of my bio and clicked the Update from GitHub button
I'm using the latest stable chrome release on Ubuntu 16.04.
I will try a different browser later today

Hi Stuart,
These silly emoji are popping everywhere! I had one knowledgeable insist that they are ASCII, but they can't be.
But WHAT are these nutty things:  ? ? ? ? ?
od -c shows: 360 237 215 252
od -x shows: 9ff0 aa8d 000a
This is just driving me batty!
Steve

From: Stuart Taylor<EMAIL_ADDRESS>Sent: Friday, September 23, 2016 3:50:40 PM
To: FreeCodeCamp/FreeCodeCamp
Subject: Re: [FreeCodeCamp/FreeCodeCamp] Added emoji support for Bio (#10823)
No no, these are GitHub emoji
? ? ? ? ?

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/FreeCodeCamp/FreeCodeCamp/pull/10823#issuecomment-249229605, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACKXS0K8A61vB97coiV8jtwBCtJyGom7ks5qs_VQgaJpZM4KB5kV.

@dhcodes, this should finally be good to go!

Still the same for me...

cc/ @FreeCodeCamp/issue-moderators, anyone else having the same issue as @Bouncey? I personally still can't reproduce.

@atjonathan you're not encountering this yourself? Is it possible that this could be caused by our custom CSS rules or by Bootstrap?

I can't repro this on Mac, but I can (kind of) on Windows. I don't get black and white emojis on Windows, but I do get a flat style of emoji, rather than the 3D looking ones I'm used to. I would guess this is due to our font stack. If you check out the Github CSS you'll see they add a special class around emojis which gives them the following font stack:
"Apple Color Emoji", "Segoe UI", "Segoe UI Emoji", "Segoe UI Symbol"

@ltegman, could you attach a screenshot?
@QuincyLarson, no, I can't reproduce.

@ltegman I think you are right. I guess it depends on the fonts you have installed on your machine.
I didn't test this particular case, but I already had troubles with emojis on my Ubuntu system because of missing fonts.

From the forum post linked by @Em-Ant

In addition to the Apple Color Emojis being proprietary, I'm pretty sure Ubuntu doesn't support colour bitmap fonts.
So, for use in single documents, you can fall back to images

Not supported in Ubuntu, needs an image fallback

@ltegman :+1:

@ltegman can this be merged?

I was just waiting to see if there were any remaining concerns now that we know the rendering issue is down to installed fonts, but it looks like there isn't 👍


expire tokens on changing password

after changing my password my old tokens are still working, I think changing password should expire all old tokens,
I didn't find anything about that on docs, so I think it an issue with drf-jwt

How about saving the jwt to db (redis or something), while authenticating check the jwt and is_jwt_in_db() else return false,
So on password change or phone stolen scenario it will not authenticate?

We could hash the secret with values extracted from the user.
think password for instance. Once you change one of the values, the signature will never be the same again. Thus invalid existing token for the user.
We could expose a list of attributes or a callable on the configuration layer to allow fine control for end users.

Can you please describe the details? (What should I change in the source code that token sense password change)

@ticosax Any reason not to just append the last few characters of the user's hashed password as a field on the token? This seems worth doing since right now if a user's token gets leaked there isn't any way to revoke all of their previous tokens.

@serj1975 did you check the proof of concept in #112 ?
@Alex3917 I don't really grok your suggestion. Can you provide an example ?

@ticosax
When a user creates a password, it gets hashed into something like:
pbkdf2_sha256$20000$FhnlJ0rpdCli$SHBxdnk2xUMmJgok//3YaC89uVJG0eu4xz14pWAakKE=
So when when a user obtains a new JWT, you would add, say, the last 15 characters of that user's password to the token:
jwt.update({ "lucky_numbers": "eu4xz14pWAakKE=" })
And then every time you validate the JWT, you check to see if the 'lucky_numbers' field on the token matches the list 15 characters on the user's password. If not, you raise an exception, and the token is no longer valid.
This is seems like a pretty good solution because you already need to lookup a user object to both create and validate a JWT, so there wouldn't be any extra database lookups. You could also add a DateTime field on the user model called something like 'password_last_changed_at', and invalidate all tokens issued before that timestamp. However, this involves forcing the user to add an extra field to their user model, and only really helps in the one in a quadrillion case that the last 15 digits of the old password hash are the same as for the new password hash.

I also would like the token to be invalidated when pw changes.

@Alex3917 thank you for the detailed explanation.
Your suggestion is viable, it rely on private claims names https://tools.ietf.org/html/rfc7519#section-4.3 of the spec.
I'd say it could be considered as an alternative implementation, If we are not afraid to expose part of the hashed password. Which is something I'm not qualify to assert it is a safe operation !
Your suggestion has something better than mine also, is that, it can be pluggable and doesn't seems to require to change the internal API of drf-jwt.

@ticosax I'm not a mathematician, but assuming the user is using the default password storage mechanism, and a secret key of comparable strength to the default secret key, then I'm guessing it would take longer than the expected length of the universe to get the password from the partial hash.
The one issue I can think of here is if the user isn't using the default django password storage, e.g. if they mapped the user's password field to a preexisting database field that stores the passwords in plaintext or using a simple md5 hash or whatever. So if implemented there should probably be an option to disable this functionality, as well as a couple sentences about potential security implications.

What about sha1(user.password + SECRET_KEY) ? So later on you are just validating signatures and if it does not match – reject a token.

here is my workaround, I used this solution in our project (Pseudocode here), it may be helpful for this discussion:
I added this model to my app:
#models.py
class Token(models.Model):
    user= models.ForeignKey(settings.AUTH_USER_MODEL)
    token = models.CharField(max_length=200)
    password = models.CharField(max_length=200)

then I created my encode handler to add token to my db:
from rest_framework_jwt.utils import jwt_encode_handler
def my_encode_handler(payload):
    token = jwt_encode_handler(payload)

    current_password = get_user_model().objects.get(id=payload["user_id"]).password
    token.objects.create(payload["user_id"], token, current_password)

    return token

and then here is my decode handler
import jwt
from rest_framework_jwt.utils import jwt_decode_handler
def my_decode_handler(token):
    payload = jwt_decode_handler(token)

    user_id = payload.get("user_id")
    user = get_user_model().objects.get(id=user_id)

    try:
        Token.object.get(
            user=user,
            token=token,
            password=user.password # so if user have changed password they wont match here
        )
        return  payload
    except Token.objects.DoesNotExist:
            msg = 'can not use token'
            raise jwt.ExpiredSignature(msg)

so when user changes her password, my_decode_handler will stop login for old tokens
or when they logout i simply pop that token from our db,

So you basically killed all benefits of jwt? I think much easier would be using own payload generator + custom verification method.
Dnia 02.10.2015 o godz. 15:35 Ali Vakilzade<EMAIL_ADDRESS>napisał(a):

here is my workaround, I used this solution in our project (Pseudocode here), it may be helpful for this discussion:
I added this model to my app:
#models.py
class Token(models.Model):
user= models.ForeignKey(settings.AUTH_USER_MODEL)
token = models.CharField(max_length=200)
password = models.CharField(max_length=200)
then I created my encode handler to add token to my db:
from rest_framework_jwt.utils import jwt_encode_handler
def my_encode_handler(payload):
token = jwt_encode_handler(payload)
current_password = get_user_model().objects.get(id=payload["user_id"]).password
token.objects.create(payload["user_id"], token, current_password)

return token

and then here is my decode handler
import jwt
from rest_framework_jwt.utils import jwt_decode_handler
def my_decode_handler(token):
payload = jwt_decode_handler(token)
user_id = payload.get("user_id")
user = get_user_model().objects.get(id=user_id)

try:
    Token.object.get(
        user=user,
        token=token,
        password=user.password # so if user have changed password they wont match here
    )
    return  payload
except Token.objects.DoesNotExist:
        msg = 'can not use token'
        raise jwt.ExpiredSignature(msg)

so when user changes her password, my_decode_handler will stop login for old tokens
or when they logout i simply pop that token from our db,
—
Reply to this email directly or view it on GitHub.

Anybody found solutions to this?

@sandipbgt In light of issue 244, adding a password_last_change datefield to your user model is definitely a better solution than using a part of the password hash, since having that datefield can also be used to prevent that attack.

+1 , any solution for this guys?

from rest_framework.authtoken.models import Token
def update (request):
""change the password""
Token.objects.get(user_id=request.user.id).delete()
Token.objects.create(user_id=request.user.id)

Seems like including part of the password hash in the token itself is not a great idea.  I doubt anyone here has a strong enough background in cryptography to say with confidence that this would not significantly reduce the key space for an attacker.

My solution is calling the delete() token method after .save() the object:
user.set_password(...)
user.save()
token = user.get_auth_token()
token.delete()


[BUG] Prevent password suggester from appearing in dataset selector

Recently Chrome's password suggester has been popping up when I click into the dataset selector in the App 😞
I am unsure if this started happening due to a browser update or if some metadata was changed on the component in FiftyOne, but can something be done to tell Chrome to stop doing this???

@brimoor I am using Chrome (Version 107.0.5304.110 (Official Build) (arm64)) and had the chrome password manager turned on for all settings. Cannot duplicate this bug. Could you provide more info about the environment?

No longer seeing this.


Alpha support for generating yaml only

With this change:
kubectl kots install --yaml --offline --kotsadm-tag 1.16.1 appname > kotsadm.yaml

will generate the admin console yaml for kots 1.16.1

Closing this one in favor of the more kots install to existing airgap cluster workflow. This can be revisited in the future, but at this time, it's not planned.


Android Build error ARMV7A

when I'm going to build a build for android, this error appears... does anyone know how to solve it?
error: attributes 'armv7a' missing
at /nix/store/bblbjmnzfib5q0r7xbk1c920bsabbw-source/pkgs/development/tools/build-managers/meson/default.nix:84:21

Hello!
Thank you for your bug report!
I tried reproducing your issue with the obelisk skeleton project and the following versions:
NixOS: nixpkgs-22.05
Obelisk: master (https://github.com/obsidiansystems/obelisk/commit/e3ec75f6988eed47189dd20f8c8514748b33ea81) and develop (https://github.com/obsidiansystems/obelisk/commit/1e357e1e965d876a36eafa1631e365b7df24c274)
All versions seem to work fine, and I was able to deploy the android build to my phone.
Is this issue still relevant, or can you share more information about your project?

arm v7 is no longer supported, due to this issue


terragrunt running within a container is killed without error

i have a strange issue where i run terragrunt inside a container. after building and running the container i can plan and apply just fine but after some time terragrunt starts failing without any error beside Killed in the terminal. restarting the container fixes the issue but as i plan to start using this container for automation, it might cause some issues.
i tried to export TF_LOG=DEBUG but still no output which leads me to understand the command is never passed into terraform and is killed before the tf binary execution. also tried running the command with --terragrunt-debug and still nothing... will appreciate some direction on how to debug this. thanks

Killed indicates that some OS process is killing the process (perhaps OOM? or stdout buffer limits?). When there is a fatal error caused by terragrunt or terraform itself, you should get a panic log and traceback.
I would look into monitoring the container resource usage as terragrunt runs to see if there are resource issues (see docker container top and docker container stats).
The most likely cause of this that I have seen in the past is if you have a really long plan line (e.g., injecting json/text data where a single line is above the buffer limits that terragrunt uses). Do you have anything like that in your modules?

not something i know of, and i get this error for modules which for sure do not have anything like that.
the contianer does not exit so i don't think it's a container resource limit issue...where should i see these panic / trace logs?

The panic trace logs should show up in stdout and stderr where terragrunt is running.

Closing as stale. If this is still an issue, please open a follow up ticket with updated context. To get more verbose logs, you can probably do --terragrunt-log-level debug. Note that it would also help if we can get the Dockerfile and a sample project to see if we can reproduce the issue. Thanks!


System Information Leak：Internal

https://github.com/twitter/repo-scaffolding/blob/2586778ffdc133431f4cf648c13638ffed840772/add_license_headers.py#L538
An internal information leak occurs when system data or debugging information is sent to a local file, console, or screen via printing or logging.
It is recommended to use concise and ambiguous information to prompt the user

because this is only printed the console of the person running the script, showing them their own current working directory is fine.


Correct english grammar of docstrings / comments

If someone whose native language is English comes along, I would be grateful if they would update the functions and methods documentation using cleaner English than mine.

Can i take this issue up?


Adopt requirements.txt for python dependencies

Do not rely on the user manually typing things. Please adopt requirements.txt so everything can be installed automatically via pip3 install -r requirements.txt

fixed


fix: PHPStan 0.12.82 compatibility

[x] Added or updated tests
[ ] Documented user facing changes
[x] Updated CHANGELOG.md

Resolves #796
Changes

Introduced local cache to some extensions
If the generic model is the Eloquent model, some extensions are skipping some checks.

Breaking changes
none

I just tested it on our codebase, and no crashes on a complete run for us :)

@olivernybroe Thank you!
I also tested on some open source projects + my own. Everything seems fine :+1:

@canvural Very well done!

It looks like there might be some memory leaks in this
Reached internal errors count limit of 50, exiting...
     Internal error: Child process timed out after 300.0 seconds. Try making it longer with parallel.processTimeout setting.
     Child process error (exit code 255):
     In NodeScopeResolver.php line 574:

       Out of memory (allocated<PHONE_NUMBER>) (tried to allocate<PHONE_NUMBER> bytes)

     mmap() failed: [12] Cannot allocate memory

     mmap() failed: [12] Cannot allocate memory
     Fatal error: Out of memory (allocated<PHONE_NUMBER>) (tried to allocate<PHONE_NUMBER> bytes) in
     phar:///vendor/phpstan/phpstan/phpstan.phar/src/Analyser/NodeScopeResolver.php on line 574

😲
Should we make it an Issue?


Spamming WARNINGs in resque production.log

Context
We were checking resque logs to track some issues and we saw this WARNING repeated a lot.
Steps to Reproduce
Just check resque production.log.
Current Result
Tons of WARNINGs like the following ones:
WARNING: Can't mass-assign protected attributes for Carto::UserTable: name, user_id
        app/models/table.rb:59:in `initialize'
        app/models/synchronization/member.rb:475:in `new'
        app/models/synchronization/member.rb:475:in `table'
        app/models/synchronization/member.rb:444:in `geocode_table'
        app/models/synchronization/member.rb:390:in `set_success_state_from'
        app/models/synchronization/member.rb:202:in `run'
        lib/resque/synchronization_jobs.rb:13:in `block in perform'
        lib/resque/base_job.rb:21:in `run_action'
        lib/resque/synchronization_jobs.rb:10:in `perform'

WARNING: Can't mass-assign protected attributes for Carto::UserTable: user_table
        app/models/table.rb:59:in `initialize'
        app/models/table_registrar.rb:11:in `new'
        app/models/table_registrar.rb:11:in `register'
        app/connectors/importer.rb:275:in `persist_metadata'
        app/connectors/importer.rb:127:in `register'
        app/connectors/importer.rb:89:in `block (2 levels) in register_results'
        app/connectors/importer.rb:88:in `each'
        app/connectors/importer.rb:88:in `block in register_results'
        lib/carto/bolt.rb:29:in `run_locked'
        app/connectors/importer.rb:87:in `register_results'
        app/connectors/importer.rb:74:in `run'
        app/models/data_import.rb:852:in `execute_importer'
        app/models/data_import.rb:441:in `dispatch'
        app/models/data_import.rb:189:in `run_import!'
        lib/resque/importer_jobs.rb:9:in `block in perform'
        lib/resque/base_job.rb:21:in `run_action'
        lib/resque/importer_jobs.rb:9:in `perform'

@CartoDB/rt-managers Let's tackle this via RT, should be a quick fix and will help infra to better read logs.
Thanks!

Closing in favor of https://app.clubhouse.io/cartoteam/story/83595/spamming-warnings-in-resque-production-log


Check all remote ICE candidates in Rtc::accepts()

Sometimes, a WebRTC client will send e.g. DTLS traffic using a candidate pair that has been found successful, but is not the currently nominated pair. In my local tests, this only happens as the connection is being established. My guess is a race condition - if multiple pairs are nominated in sequence, it's possible for traffic to come in via an old nomination before the new one reaches the remote client and takes effect.
If this happens, Rtc::accepts() will reject the traffic due to not being from the current nominated pair. I noticed this while working with Firefox, but it may happen in other WebRTC clients as well. I also noticed that occasionally Firefox will get stuck using the same not-nominated pair to retry DTLS that failed in this manner (although I imagine such behavior is not intended).
To minimize the performance impact, we continue to eagerly check against the nominated pair, and only fallback to checking all candidates as a last resort.

That's true, it would be a good idea to sanity check candidates first. I can also try digging into libwebrtc source a bit and see if I find anything.

I digged into libwebrtc source a bit. It seems they have similar logic for deciding what to forward, complete with a fast path for the selected one. Here, Connection basically boils down to a candidate pair, with one created for every non-pruned local-remote combination.
The "non-pruned" bit may be important to us as well, in the spirit of the security consequences you mentioned. libwebrtc seems to prune candidates whose networks have disappeared, or when a re-gather is initiated. str0m's equivalent seems to be discarded?

We could then take one of a few approaches:

Check all non-discarded remote candidates for a matching source address.
Check all candidate pairs with CheckState::Succeeded for a remote candidate with a matching source address (this automatically excludes discarded candidates).
The second solution, but also check the local candidate against the destination address.

Which of these do you feel is most appropriate?

I think 2 is a good choice. If it succeeded, we have got a successful request-response. That might match libWebRTC logic here.


Updated FAQ + Fixed answers + removed duplicates + organized in sections

Better organization of the FAQ section.

Seems as obsolete. Let me know if it is still relevant. Close it for now


Remove RecursiveOpenStruct dependency

Hey,
An awesome gem you've got there!
I've figured out there was an unnecessary recursive-open-struct dependency (same behavior could be reached with just standard json and ostruct libraries), so here is the PR.
Do you maintain/support the gem still, btw?
Best,
Sergey

Also please note that payload attribute is now private. It wasn't covered in specs or used anywhere in code outside the class, so I assumed it's safe - however if someone, for whatever reason, uses payload on Blanket::Response object in their code, then it might cause problems - tell me if that's the case and you think it's best to keep that public

Hi, thanks a lot for your contribution!
Somehow Github neglected to email me about your PR, that's why I'm only seeing this now 😄.
Great catch on removing this dependency, thanks!

Regarding the payload attribute, it shouldn't be a problem. Anyway, since it was a public method, I'll bump the version before releasing the next version of the gem.


Adjust camera bounds according to screen size

Depending on resolution, our camera box collider scale needs to be dynamically changed

Starting this now!

Simply need to adjust camera size and Ui canvas according to aspect ratio! wouldnt be too hard!
http://gamedev.stackexchange.com/questions/79546/how-do-you-handle-aspect-ratio-differences-with-unity-2d/89973#89973
http://forum.unity3d.com/threads/get-aspect-ratio.211255/
http://docs.unity3d.com/ScriptReference/Camera-aspect.html
http://docs.unity3d.com/ScriptReference/UI.CanvasScaler.html

Fixed via commit a3e3e7794bb227457fad7ad392cbb85cf3cd566d
The vertical scaling may be a bit wonky (which could be fixed in a later issue), but you can no longer walk out of the camera!

Addressed in issue #31


[Core]: ValueError: Out of range float values are not JSON compliant

System Info
hosted
Reproduction
add with empty data maybe?
Expected behavior
ValueError: Out of range float values are not JSON compliant
at .iterencode ( /usr/local/lib/python3.10/json/encoder.py:257 )
at .encode ( /usr/local/lib/python3.10/json/encoder.py:199 )
at .dumps ( /usr/local/lib/python3.10/json/init.py:238 )
at .render ( /usr/local/lib/python3.10/site-packages/starlette/responses.py:199 )
at .init ( /usr/local/lib/python3.10/site-packages/starlette/responses.py:55 )
at .init ( /usr/local/lib/python3.10/site-packages/starlette/responses.py:196 )
at .add ( /usr/local/lib/python3.10/site-packages/embedbase/app.py:164 )
at .run_endpoint_function ( /usr/local/lib/python3.10/site-packages/fastapi/routing.py:163 )
at .app ( /usr/local/lib/python3.10/site-packages/fastapi/routing.py:237 )
at ._sentry_app ( /usr/local/lib/python3.10/site-packages/sentry_sdk/integrations/fastapi.py:130 )
at .app ( /usr/local/lib/python3.10/site-packages/starlette/routing.py:66 )
at .handle ( /usr/local/lib/python3.10/site-packages/starlette/routing.py:276 )
at .call ( /usr/local/lib/python3.10/site-packages/starlette/routing.py:718 )
at .call ( /usr/local/lib/python3.10/site-packages/fastapi/middleware/asyncexitstack.py:18 )
at .call ( /usr/local/lib/python3.10/site-packages/fastapi/middleware/asyncexitstack.py:21 )
at ._create_span_call ( /usr/local/lib/python3.10/site-packages/sentry_sdk/integrations/starlette.py:130 )
at .call ( /usr/local/lib/python3.10/site-packages/starlette/middleware/exceptions.py:68 )
at .call ( /usr/local/lib/python3.10/site-packages/starlette/middleware/exceptions.py:79 )
at ._create_span_call ( /usr/local/lib/python3.10/site-packages/sentry_sdk/integrations/starlette.py:130 )
at ._sentry_exceptionmiddleware_call ( /usr/local/lib/python3.10/site-packages/sentry_sdk/integrations/starlette.py:229 )
at .coro ( /usr/local/lib/python3.10/site-packages/starlette/middleware/base.py:70 )
at .call_next ( /usr/local/lib/python3.10/site-packages/starlette/middleware/base.py:84 )
at .dispatch ( /middlewares/auth_api_key/auth_api_key.py:182 )
at .call ( /usr/local/lib/python3.10/site-packages/starlette/middleware/base.py:108 )
at ._create_span_call ( /usr/local/lib/python3.10/site-packages/sentry_sdk/integrations/starlette.py:130 )
at .simple_response ( /usr/local/lib/python3.10/site-packages/starlette/middleware/cors.py:146 )
at .call ( /usr/local/lib/python3.10/site-packages/starlette/middleware/cors.py:91 )
at ._create_span_call ( /usr/local/lib/python3.10/site-packages/sentry_sdk/integrations/starlette.py:130 )
at .call ( /usr/local/lib/python3.10/site-packages/starlette/middleware/errors.py:162 )
at .call ( /usr/local/lib/python3.10/site-packages/starlette/middleware/errors.py:184 )
at ._create_span_call ( /usr/local/lib/python3.10/site-packages/sentry_sdk/integrations/starlette.py:130 )
at .call ( /usr/local/lib/python3.10/site-packages/starlette/applications.py:122 )
at ._run_app ( /usr/local/lib/python3.10/site-packages/sentry_sdk/integrations/asgi.py:183 )
at ._run_app ( /usr/local/lib/python3.10/site-packages/sentry_sdk/integrations/asgi.py:188 )
at ._run_asgi3 ( /usr/local/lib/python3.10/site-packages/sentry_sdk/integrations/asgi.py:139 )
at ._sentry_patched_asgi_app ( /usr/local/lib/python3.10/site-packages/sentry_sdk/integrations/starlette.py:335 )
at .call ( /usr/local/lib/python3.10/site-packages/fastapi/applications.py:276 )
at .call ( /usr/local/lib/python3.10/site-packages/uvicorn/middleware/proxy_headers.py:78 )
at .run_asgi ( /usr/local/lib/python3.10/site-packages/uvicorn/protocols/http/httptools_impl.py:435 )

already done https://github.com/tiangolo/fastapi/issues/459

maybe doing some df.fillna()
todo: write unit test that reproduce this

fixed


[GSSOC'21] STRING (Anagram)

I would like to add a program to find anagrams of string
discord: diksha#6684
@avijit1999 @tarun26091999 @dheerajkotwani @anubhavitis

hello @tarun26091999  @rudrakshi99 can i work on this issue in c++.
Thank you!

issue present at #395


fix: ensure to use local synchronous_commit in managed role

closes: #3142

Started an E2e run on the EDB repo to spare some OSS workers: https://github.com/EnterpriseDB/cloudnative-pg/actions/runs/6628815021


Align docs and dependencies

[x] upgrade project_options
[ ] consider forking project_options
[x] update cmake version required
[x] check documents for required compilers/C++ verison

Note @ddalcino this is based onto develop so it can easily be fully vetted before merging.

Codecov Report

Merging #18 (1a5972a) into develop (f37c1ab) will decrease coverage by 3.70%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop      #18      +/-   ##
===========================================
- Coverage    77.77%   74.07%   -3.71%
===========================================
  Files            3        3
  Lines           36       27       -9
  Branches        19        0      -19
===========================================
- Hits            28       20       -8
  Misses           7        7
+ Partials         1        0       -1

Flag
Coverage Δ

Linux
?

Windows
74.07% <ø> (-5.93%)
:arrow_down:

macOS
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/main.cpp
22.22% <0.00%> (-20.64%)
:arrow_down:

test/tests.cpp
100.00% <0.00%> (ø)

test/constexpr_tests.cpp
100.00% <0.00%> (ø)

Continue to review full report at Codecov.

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

According to https://en.cppreference.com/w/cpp/compiler_support, there are still C++20 features that are as yet unsupported by clang. GCC 11 and the current release of Visual Studio 2019 both have full support for C++20.
It's possible that earlier versions of clang, GCC, and MSVC can successfully compile cpp_boilerplate_project. However, I think it's disingenuous to tell our users that an older version will work when they start using C++20 features that aren't demonstrated in the project.
It is my contention that we are already testing the oldest compilers that are compatible with the project; we just need to update the README to reflect the new versions.

Is there anything left to do here?
Do we really need to fork project_options? Honestly, I don't see a pressing need to do so at the moment. I am tempted to just watch and wait until something breaks.

Whoa, that merge really didn’t work out. I’m not clear on what happened to Visual Studio, and I really wasn’t expecting the template janitor to fire. Any ideas here?


Cannot deploy cluster if selecting Open Source & Private Cluster

Landing on the helper, selecting Open Source and Private should result in a deployable configuration, currently, it doesnt

Is this still a problem @khowling ?

As per convo with Keith... We just need to downgrade a Validation Error message to a Warning.


If the calendar type is selected in Windows AD, then the date picker shell will also be AD, even if the culture info is set to fa-IR.

Describe the bug
I set the culture info in startup.configure as follows:
var cultureInfo = new CultureInfo("fa-IR");
CultureInfo.DefaultThreadCurrentCulture = cultureInfo;
CultureInfo.DefaultThreadCurrentUICulture = cultureInfo;
CultureInfo.CurrentCulture = cultureInfo;
CultureInfo.CurrentUICulture= cultureInfo;

However, the date picker shell will also be AD as follows, Only the names of the Gregorian months are shown in Persian.:

The problem still persists even if the culture is set as follows in date picker:
<BitDatePicker @bind-Value="LetterModel.AtfPyroDate" Style="width: 300px" AllowTextInput="true" FormatDate="yyyy/MM/dd" GoToToday="امروز" Culture="@(new System.Globalization.CultureInfo("fa-IR"))"></BitDatePicker>

Now, if the Windows calendar is set to Hijri, this problem will be solved as follows:

I also tried to customize the names of the months as shown below, but this time I did not succeed.
var cultureInfo = CultureInfo.CreateSpecificCulture("fa-IR");
cultureInfo.DateTimeFormat.MonthNames = new[] { "فروردین", "اردیبهشت", "خرداد", "تیر", "مرداد", "شهریور", "مهر", "آبان", "آذر", "دی", "بهمن", "اسفند", "" };

The problem is that in Windows 7 or other operating systems, it may not be possible to set the calendar to Hijri.
How should we set the culture info so that the date picker shell is displayed in Persian in any case?
Expected behavior
It is better not to follow the system culture by setting the date picker culture anymore.
Bit Blazor client
Bit nuget package's version. 11.0.0
Blazor Server or Blazor Web Assembly or both? Blazor Server
Which browser? Chrome Version 102.0.5005.63 (Official Build) (64-bit)
Which blazor version? blazor 6

I appreciate your detailed issue @Kamalifar
By Windows 7, is aspnetcore server that runs blazor server is running in Windows 7? Or only the browser is running in Windows 7 and server is somewhere else?

Thank you for your prompt reply @ysmoradi.
Only the browser is running in Windows 7 and the server is somewhere else.
However, For different modes. Suppose the server operating system is a CentOS 5 and users are using Windows 7 or even Ubuntu.

Ok, could you please provide a small repo that reproduces this?

I also tried to customize the names of the months as shown below, but this time I did not succeed.
var cultureInfo = CultureInfo.CreateSpecificCulture("fa-IR"); cultureInfo.DateTimeFormat.MonthNames = new[] { "فروردین", "اردیبهشت", "خرداد", "تیر", "مرداد", "شهریور", "مهر", "آبان", "آذر", "دی", "بهمن", "اسفند", "" };

Note that we're using this line of code in BitDatePicker
private CultureInfo culture = CultureInfo.CurrentUICulture;

Unfortunately, I did not understand what I have to provide?

A sample source code that has this issue

I used this code in the following ways.

<BitDatePicker @bind-Value="LetterModel.AtfPyroDate" Style="width: 300px" AllowTextInput="true" FormatDate="yyyy/MM/dd" GoToToday="امروز" Culture="@cultureInfo"></BitDatePicker>
@code {  protected override void OnAfterRender(bool firstRender)     {         base.OnAfterRender(firstRender);         if (firstRender)         {             cultureInfo.DateTimeFormat.MonthNames = new[] {"فروردین", "اردیبهشت", "خرداد", "تیر", "مرداد", "شهریور", "مهر", "آبان", "آذر", "دی", "بهمن", "اسفند", ""};         }     } }

<BitDatePicker @bind-Value="LetterModel.AtfPyroDate" Style="width: 300px" AllowTextInput="true" FormatDate="yyyy/MM/dd" GoToToday="امروز"></BitDatePicker>
In startup:
 public void Configure(IApplicationBuilder app, IWebHostEnvironment env)         {             var cultureInfo = CultureInfo.CreateSpecificCulture("fa-IR");             cultureInfo.DateTimeFormat.MonthNames = new[] { "فروردین", "اردیبهشت", "خرداد", "تیر", "مرداد", "شهریور", "مهر", "آبان", "آذر", "دی", "بهمن", "اسفند", "" };             CultureInfo.DefaultThreadCurrentCulture = cultureInfo;             CultureInfo.DefaultThreadCurrentUICulture = cultureInfo;             CultureInfo.CurrentCulture = cultureInfo;             CultureInfo.CurrentUICulture = cultureInfo;

<BitDatePicker @bind-Value="LetterModel.AtfPyroDate" Style="width: 300px" AllowTextInput="true" FormatDate="yyyy/MM/dd" GoToToday="امروز" Culture="@cultureInfo"></BitDatePicker>
@code { public CultureInfo cultureInfo = CultureInfo.CreateSpecificCulture("fa-IR");     protected override void OnInitialized()     {         base.OnInitialized();         cultureInfo.DateTimeFormat.MonthNames = new[] {"فروردین", "اردیبهشت", "خرداد", "تیر", "مرداد", "شهریور", "مهر", "آبان", "آذر", "دی", "بهمن", "اسفند", ""};     } }
In the first mode, nothing happens. But in the second and third modes, only the month changes, but the year and day remain the same(AD).

@Kamalifar
could you please create a new GitHub repository, push your code into it, and post the address of that repo?

BTW, I think it's an issue of the OS itself since in windows 10 and 11 we are seeing such an experience

I think it's an issue of the OS itself since in windows 10 and 11 we are not seeing such an experience

Exactly, I am testing this on Windows 10. This problem occurs if the Gregorian calendar is selected, but if the Hijri calendar is selected, the problem will be solved.

you please create a new GitHub repository, push your code into it, and post the address of that repo?

https://github.com/Kamalifar/TestBitComponentDatePicker/

Describe the bug I set the culture info in startup.configure as follows:
var cultureInfo = new CultureInfo("fa-IR");
CultureInfo.DefaultThreadCurrentCulture = cultureInfo;
CultureInfo.DefaultThreadCurrentUICulture = cultureInfo;
CultureInfo.CurrentCulture = cultureInfo;
CultureInfo.CurrentUICulture= cultureInfo;

However, the date picker shell will also be AD as follows, Only the names of the Gregorian months are shown in Persian.:

The problem still persists even if the culture is set as follows in date picker:
<BitDatePicker @bind-Value="LetterModel.AtfPyroDate" Style="width: 300px" AllowTextInput="true" FormatDate="yyyy/MM/dd" GoToToday="امروز" Culture="@(new System.Globalization.CultureInfo("fa-IR"))"></BitDatePicker>

Now, if the Windows calendar is set to Hijri, this problem will be solved as follows:

I also tried to customize the names of the months as shown below, but this time I did not succeed.
var cultureInfo = CultureInfo.CreateSpecificCulture("fa-IR");
cultureInfo.DateTimeFormat.MonthNames = new[] { "فروردین", "اردیبهشت", "خرداد", "تیر", "مرداد", "شهریور", "مهر", "آبان", "آذر", "دی", "بهمن", "اسفند", "" };

The problem is that in Windows 7 or other operating systems, it may not be possible to set the calendar to Hijri. How should we set the culture info so that the date picker shell is displayed in Persian in any case?
Expected behavior It is better not to follow the system culture by setting the date picker culture anymore.
Bit Blazor client
Bit nuget package's version. 11.0.0 Blazor Server or Blazor Web Assembly or both? Blazor Server Which browser? Chrome Version 102.0.5005.63 (Official Build) (64-bit) Which blazor version? blazor 6

@Kamalifar
Thanks a lot for contributing and submitting such a detailed and clear issue.
If you want to use the BitPlatform products widely in your projects, we can give you priority support for free, so in case you have an issue, you can contact the BitPlatform development team at MicrosiftTeams very quickly and get your answer ASAP.
If you would like to have this support plan, let us know and send us your email.

Dear @maryamhdr,
Thanks for your support and explanation.
I'd like to use the BitDatePicker widely in my projects, So my email address is<EMAIL_ADDRESS>Best Regards,
Ali Kamalifar

You've been invited to the Microsoft teams. Give it a try! @Kamalifar

I was able to achieve followings

Source code:
https://github.com/bitfoundation/bit-components-playground/tree/issue-2188
There is an issue with CultureInfo.TextInfo.IsRightToLeft property which needs more investigation

Thank you so much for all you have done.
I used your code and the result is the same as before, as you can see in the picture.

Source code:
https://github.com/Kamalifar/TestBitComponentDatePicker/blob/master/Pages/TestCultureInfoHelper.razor
Although today's date is selected, which means the 9th day of July, it displays the calendar of Mehr 2022, which means that only the month array mapping is done and the main date picker of the Gregorian calendar remains. July is the seventh month of the year and Mehr is the seventh month of the Shamsi year.
Please, first change the server calendar to Gregorian and then run the project. If the server calendar is changed while running, then the problem will not be seen.
Regards.

Please use latest version of "Bit.BlazorUI" package, not "Bit.Client.Web.BlazorUI".
And could you please let me know if https://github.com/bitfoundation/bit-components-playground/tree/master/src/client/Pages/Issues/2188
Works for you by cloning and running that repo
Thanks in advance

Thank you and congratulations.
https://github.com/bitfoundation/bit-components-playground/tree/master/src/client/Pages/Issues/2188 works for me very well, but it only works for WebAssembly, and unfortunately it doesn't work for BlazorServer.
It seems that the reflection has been useful, but probably some changes should be made for BlazorServer.
I updated https://github.com/Kamalifar/TestBitComponentDatePicker based on "Bit.BlazorUI" package, however, the result is the same as before.

I ran your sample and it works like a chart. It seems that there is something OS-dependent is causing the issue
Could you please run your sample in Clean Windows 10 in Virtual Machine or elsewhere?
We can test Windows Server / Linux / Windows 7 after that.
Plus provide me cultureData values in your current setup as followings:

This is your sample repo working totally fine on Windows 10
It seems that you've made it better by using fonts (Looks better than my sample)

It has some differences. Your default calendar is GreorianCalendar, mine is PersianCalendar
That's the issue

Yes, exactly, but why is it still affected by the operating system calendar? only in Blazor Server.
The below picture is my cultureData value in WebAssembly test project.

Try this approach and let un know if this works or not
https://stackoverflow.com/a/15826881/2720104

I tried to do this, but it can't do the cast on the following line.
newOptionalCalendarIDs[i] = (Int32) idProperty.GetValue(optionalCalendars[i], null);

I will leave the address of the code, please do a test.

I'm afraid we can't truly test this because this needs an OS which problem exists in there and we don't have such an OS installed. And believe me or not, this is not BitDatePicker's issue, but we'll merge any PR you make if you wanna put more effort into this

We're going to use CultureInfo.DateTimeFormat.Calendar instead of CultureInfo.Calendar
This property is writable and you can change that to PersianCalendar easily

The issue is accepted and planned. Resolving it will start ASAP.

Resolving this issue has started. It will be announced when this issue is resolved.

The issue has been resolved.
Note that in this state, the issue itself gets closed.

We're going to use CultureInfo.DateTimeFormat.Calendar instead of CultureInfo.Calendar This property is writable and you can change that to PersianCalendar easily

You're right, however, I do this too but still the calendar stays in Gregorian mode.

In the new pre-release we're using CultureInfo.DateTimeInfo.Calendar which is writable
No need to change the default calendar anymore.

Dear @msynk @ysmoradi @maryamhdr,
Congratulations!
The problem has been resolved definitely.
Thank you so much,
Best regards.


Can Kong listen proxy on multiports?

I install Kong directly, don't use docker container. I want Kong listen proxy on multiports such as below configuration.
proxy_listen: "<IP_ADDRESS>:80"
proxy_listen: "<IP_ADDRESS>:81"
But Kong can't listen on the second port (81), is it right.?
If it is wrong, how to enable Kong listen on multiports.
Thanks.

Sorry, when I configure that. Kong only listen on port 81.

@jimmypk Kong can't listen to multiple ports out of the box - all you are doing is redefining the same config value, which is why it only binds to port 81 in your example. The value of proxy_listen is interpolated into the nginx config by Kong and is used as the value for the listen directive.
You could modify the nginx section of your kong.yml to define the second port - it's not pretty but it might work..

Can I add more listen port to nginx inside kong.yml?

You can add it - but you'd have to try it to see if it gives you the desired effect - you'd add it to the nginx config at the bottom of kong.yml, around this line:
https://github.com/Mashape/kong/blob/master/kong.yml#L242
You would add (using the ip you mentioned above):
listen <IP_ADDRESS>:81;
It would let you listen on an additional port that nginx would listen on - but nothing else inside kong would be multi-port aware - i'm also not sure why you want to listen on multiple ports?

Because some modules run on differrent ports.
Ok. I will change the port of application, do not change Kong.
Thanks.


chore(build): Expanding wildcard export on the index barrel to allow …

…ng2-sharebuttons to be used with closure compiler in advanced mode.
This will be more and more of an issue when angular 4 comes out, given that the use of closure compiler in advanced mode will be more common now.
This is a temporary change, once this gets implemented (which is should very soon):
https://github.com/google/closure-compiler/issues/878
...then we can go back to the wildcard export, which is nice for barrels.

Coverage remained the same at 95.673% when pulling d33ed4b5beddc246067c0c51dd4d9146bc80f7b4 on nosachamos:master into 4fe63866e03b912860db7bc95b290e23c8f3dce9 on MurhafSousli:master.


[DRAFT] Align side effects to SDK

Summary
This enables the full e2e submission of SDK side effects as of 0.1.0. At the moment we can only submit 1 due to some bug in SDK here
Checklist

[ ] moves harden to use novel conversion traits
[ ] formats on circuit
[ ] fix a bug where if side effect hardening would fail then the apply would've happened beforehand, now we make sure all fallible work first
[ ] adds balance to LocalState that is shared with SDK, now we don't need hardened versions of LocalCtx
[ ] be verbose about where the circuit logs so we don't need to have runtime spam when debugging
[ ] clean up the nested inner functions to use simple boolean variables instead of functions

Please check that your PR completes the requirements as follows

[ ] Tests have been added for bug fixes/features
[ ] Acceptance criteria from the issue has been completed

Screenshots (if applicable)

Merging since i assume the protocol issue is something fixed by further improvements and shouldn't block the merge into this feature branch


Allow to configure service account and role bindings

Follow up of the https://github.com/AzBuilder/terrakube/issues/635. It would be really good to have pre-configuration fully supported by helm chart.
Service account could be crated automatically with default value terrakube-api-service-account and configurable via .Values.executor.serviceAccountName.
Role and role bindings could be done automatically when setting .Values.executor.rbac.create.
This could unify setup by using only one tool (help).

You can use the following now @dawidmalina
api:
  serviceAccountName: "terrakube-api-service-account"
  rbac:
    create: true
    roleName: "terrakube-api-role"
    roleBindingName: "terrakube-api-role-binding"


Simplify Async code

[x] Use RxJava because it seems like the simplest option
[x] Replace TermScrapeResult with something that doesn't require iterators and inheritance
[x] Replace FutureEngine

#320


fault: use FractionalPercent for percent

Description:
The existing FaultDelay config used uint32 for the percent field which limited the user to configure percentages only in terms of whole numbers between 0 and 100. FractionalPercent allows finer control over the percent values by allowing fractions to be specified in the configuration, for example, 0.0001%.
Signed-off-by: Venil Noronha<EMAIL_ADDRESS>Risk Level: Med
Testing: Added 2 new tests and updated existing tests
Docs Changes: N/A
Release Notes: Added deprecation note and introduced FractionalPercent percentages.
Fixes #3904
/cc @rshriram

@mattklein123 thanks for the quick review! I'll address the issues you mentioned.

@rshriram do you mind doing first pass review on this?

@rshriram I've addressed the last set of comments in f14d3bc. Let me know if you still want the abort changes in this PR, or if you'd prefer it in another PR.

Same pr please. It’s a mass search and replace. Makes it easy to follow patterns

Implemented the changes to abort in 3d56b3f8.

ping @mattklein123 .. this is ready for a final pass.

@venilnoronha I think you lost some of your changes. You haven't implemented either option that matt suggested but the call sites seem to have changed

So I suggest this.. Replace all call sites of featureEnabled() with the longer version that always passes the number of buckets - But do this in a separate PR. This should essentially be a mass search-and-replace. Should have no issues with any reviewer. Then this PR will automatically reduce to the changes related to fault injection.
Alternatively, simply rename the sampleFeatureEnabled to something else like featureEnabledEx and retain changes before you followed matt's option

@rshriram I've reverted the changes and have renamed sampleFeatureEnabled to featureEnabledEx in 9b1046f.
@mattklein123 as @rshriram suggested, I'll take up option 1 in a separate PR.
Thanks,
Venil

@mattklein123 as @rshriram suggested, I'll take up option 1 in a separate PR.

I would rather do one set of changes. If you want to do option 1, can you just do that PR first, we can review/merge, and then we can merge master into this?

On a second thought, I'd prefer keeping featureEnabledEx.

@mattklein123 @rshriram thanks for reviewing/merging.


Recorder: Privatize most Recorder classes

This basically only leave public the classes that are used to run/configure the Recorder.

LGTM


[e2e]: generic push main default slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6464244191
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Tue Oct 10 03:16:15 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6477492887
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Wed Oct 11 03:16:28 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6490768100
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Thu Oct 12 03:16:30 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6503545033
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Fri Oct 13 03:17:27 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6515223081
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Sat Oct 14 03:16:02 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6521636380
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Sun Oct 15 03:16:32 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6528515100
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Mon Oct 16 03:17:20 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6542032085
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Tue Oct 17 03:43:09 UTC 2023
Tests are passing now. Closing this issue.


v3.2.0 on Mega65 fails with memory setup

Hi
I tested the compiler with a simple
print "Hello World"
the program generates unreadable random nonsens on screen.
Nevertheless, I could read the string at it's $BFxx location with the monitor program.
The library code of STRMOV and PrintStr works as expected.
After changing the library file "stack.asm" the result was fine and the hello program sent greetings.
I reduced the STACKFRAME_TOP from $BF00 to $7F00.
It seems there is a difference between reading & writing bytes to locations above $8000 (upper 32K)
My environment is:
Mega665 emulator with Xemu<PHONE_NUMBER>1838-master,
Mega65 rom version is 920377;
desktop is a Mac (MacOS 10.15.7)

I have no issues with the original memory setup.
I'm using a newer version of the emulator:
Xemu:<PHONE_NUMBER>4849 official-build
ROM version: 920377
Can you upgrade xemu and try again?

I updated Xemu, but the result is the same. Even on a windows laptop.
Printstring reads from $BFF3 in bank 2.

Interesting. The exact same code works for me as expected.

I asked in a forum to bring some light in this mapping issue.

it is related to the default mappings and the simple solution is to disable the C64 ROM (funny, but it works)
I included a POKE 1,53 into the startup code and the "hello" program worked as expected.
This issue is solved now.
       ENDM
\ No newline at end of file
--- 235,238 ----
        eor .TRIG
        and .MASK
        beq .loop
!       ENDM

FYI: We're considering changing the MEGA65 boot state to make this the default. It's a backwards incompatible change so would need to be tested carefully, and setting it explicitly from the program would make it work with previous ROMs. https://github.com/MEGA65/mega65-rom-public/issues/61


DOTJ013E Error: Failed to parse referenced Markdown file

Steps to reproduce

Check out latest version of DITA-OT core repo: https://github.com/dita-ot/dita-ot/commit/3505712bf36f86ad951d675a044a6de000c191be.

Run Gradle build in core repo clone: ./gradlew.

Clone latest version of Markdown plug-in repo https://github.com/jelovirt/dita-ot-markdown/commit/0031249ddf693c01006a1e386f06d0f3cb396825 to separate directory
(outside of core repo clone).

Run ./gradlew dist to generate the plug-in distribution package.

Install resulting distribution package into core repo clone:
  dita --install path/to/build/distributions/com.elovirta.dita.markdown_1.3.0.zip

Copy test.md from Markdown plug-in repo to some local DITA project, such as DITA-OT docs.

Add topic reference to test.md.
 <topicref href="test.md" format="markdown"/>

Build output for DITA project, build fails with error:

[DOTJ013E][ERROR] Failed to parse the referenced file
    'file:/.../docs/user-guide/test.md'.: com.elovirta.dita.markdown.MarkdownReader

Reproduced on second machine to rule out local configuration errors.

Does the error message on step 8 actually contain file:/.../docs/user-guide/test.md?

Yes, though the actual path has been simplified/anonymized here with /.../.
The docs/user-guide/test.md part is the location to which the test file was copied in Step 6.

Can't reproduce this. Could you add Gist for complete verbose log?

Closing issue as invalid. I had tried building via Ant and Gradle without the necessary classpath entries.
When the build is run via the dita command, the classpath is set correctly and the build completes as expected.


Enhance board/board.mk compilation capabilities

Summary
When using the common directory, some etc resources can be placed under common/etc to reduce the storage of duplicate resources.
The purpose of this change is to perform resource search logic during the compilation process without affecting the original makefile:
This expectation will first search whether the resource specified by the makefile is stored in the private src/etc. If it does not exist, it will then search whether the resource exists under common/etc.
If the resource does not exist under common/etc, the path will eventually be spliced back to the original target (i.e. src/etc under the private path)
Impact
During the compilation process, the search logic for resource expansion
Testing
The local test passed.
Add the resource file (etc/test) that needs to be compiled in the configured src/makefile, and the resource file is only stored under common/etc. Finally, the content of common/etc/test can be successfully retrieved.

@crafcat7 I thinking about another enhancement: we could simplify the boards commons!
I think we could create a boards/common_drivers/ to move many sensors from boards/xxx/yyy/common. If you look there you will see that many I2C sensors, SPI sensors, SPI LCDs, etc are basically the same code, the only change is the archname_i2cbus_initialize(), etc.
So, we could have a boards/common_drivers/mapper.h that basically creates an alias, for example
#ifdef CONFIG_STM32
#define generic_i2cbus_initialize stm32_i2cbus_initialize
#endif
So, all sensors will use that generic_i2cbus_initialize() and it will work because the alias will be created.
What do you think?

could we put to common/drivers to avoid modifying the common Makefile again? @acassis

@crafcat7 I thinking about another enhancement: we could simplify the boards commons!
I think we could create a boards/common_drivers/ to move many sensors from boards/xxx/yyy/common. If you look there you will see that many I2C sensors, SPI sensors, SPI LCDs, etc are basically the same code, the only change is the archname_i2cbus_initialize(), etc.
So, we could have a boards/common_drivers/mapper.h that basically creates an alias, for example #ifdef CONFIG_STM32 #define generic_i2cbus_initialize stm32_i2cbus_initialize #endif
So, all sensors will use that generic_i2cbus_initialize() and it will work because the alias will be created.
What do you think?

This seems to be a good way to minimize the use of duplicate code! But it looks like it would require a lot of changes to the Makefile.
My idea is to avoid modifying the Makefile as much as possible (i.e., modify as little code as possible), and provide a way to optimize the code.

@acassis shoul we merge this patch first and refine the layout late?

+1 for merging now
design optimization can be done in a later PR


Fix users added to db multiple times

For some reason it seems users are added to the users table multiple times...?

Fixed by https://github.com/airforce270/airbot/commit/92e0cf368d14095877bb4a94d787a39e1ab25049


Does not work

I'm not sure if i'm the only one who's having this issue. But, I have been trying hours and hours to figure this out but it just doesn't work for me. I have no idea what's wrong.

i don't know if we have the same problem, but after installing shell command, and add this contents to the file config.cson
"atom-shell-commands":
commands: [
{
name: "ls"
command: "ls"
arguments: [
"{FileName}"
"-o"
"{FileNameNoExt}.exe"
]
options:
cwd: "{FileDir}"
keymap: 'ctrl-2'
}
]
nothing appear in the menu, only "stop command, go to first error, go to last error , go to next error , go to prev error"
i run atom 1.28.2 x64 on debian 9 and my config.cson is located in my home directory .atom/

I have the same issue. It appears the 'commands' key in config.cson is used by Atom. I got around this by changing the key to something else like 'commandz' and updating lines 44 and 46 in atom-shell-commands.js

do you mean :
registeredAtomCommands = [];
                    if (value != null && value != undefined &&
                            value.commandz != null && value.commandz != undefined) {
                            // Register new commands
                            value.commandz.forEach( function( command ) {

                                    // Create an atom command for each entry

and in config.cson
"atom-shell-commands":
commands: [
{
if yes, it doesn't work for me

Yes in atom-shell-commands.js but in config.cson I changed it to...

"atom-shell-commands":
commandz: [
{ ...

Also config.cson requires proper indentation.

you are right!!! in the cut & copy i add some more space .... removed the space , now works
thanks


Deep link handler never called when initializing session with user activity

Test Conditions

iOS 9.2
iPhone 6s Plus
Branch Test Key
SDK v0.11.14

Scenario
The app is launched from a cold start via a deep link. The launchOptions passed to
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

contain an  NSUserActivity, shown below:
    {
        UIApplicationLaunchOptionsUserActivityDictionaryKey =     {
            UIApplicationLaunchOptionsUserActivityIdentifierKey = "EFC7D9B0-079E-4D04-95BD-E4A66B7C4F8C";
            UIApplicationLaunchOptionsUserActivityKey = "<NSUserActivity: 0x14fd760a0>";
            UIApplicationLaunchOptionsUserActivityTypeKey = NSUserActivityTypeBrowsingWeb;
        };
    }

When calling
- (void)initSessionWithLaunchOptions:(NSDictionary *)options andRegisterDeepLinkHandler:(callbackWithParams)callback;

and passing launch options that contain the user activity, the callbackWithParams block is never called. Looking at the Branch code, session initialization gets as far as the following method, then drops through as it does not meet any of the conditions.
- (void)initSessionWithLaunchOptions:(NSDictionary *)options isReferrable:(BOOL)isReferrable explicitlyRequestedReferrable:(BOOL)explicitlyRequestedReferrable automaticallyDisplayController:(BOOL)automaticallyDisplayController {
    self.shouldAutomaticallyDeepLink = automaticallyDisplayController;

    self.preferenceHelper.isReferrable = isReferrable;
    self.preferenceHelper.explicitlyRequestedReferrable = explicitlyRequestedReferrable;

    // Handle push notification on app launch
    if ([options objectForKey:UIApplicationLaunchOptionsRemoteNotificationKey]) {
        id branchUrlFromPush = [options objectForKey:UIApplicationLaunchOptionsRemoteNotificationKey][BRANCH_PUSH_NOTIFICATION_PAYLOAD_KEY];
        if ([branchUrlFromPush isKindOfClass:[NSString class]]) {
            self.preferenceHelper.universalLinkUrl = branchUrlFromPush;
        }
    }

    if ([BNCSystemObserver getOSVersion].integerValue >= 8) {
        if (![options objectForKey:UIApplicationLaunchOptionsURLKey] && ![options objectForKey:UIApplicationLaunchOptionsUserActivityDictionaryKey]) {
            [self initUserSessionAndCallCallback:YES];
        }
        else if ([options objectForKey:UIApplicationLaunchOptionsUserActivityDictionaryKey]) {
            self.preferenceHelper.isContinuingUserActivity = YES;
            if (self.accountForFacebookSDK) {
                id activity = [[options objectForKey:UIApplicationLaunchOptionsUserActivityDictionaryKey] objectForKey:@"UIApplicationLaunchOptionsUserActivityKey"];
                if (activity && [activity isKindOfClass:[NSUserActivity class]]) {
                    [self continueUserActivity:activity];
                }
            }
        }
    }
    else if (![options objectForKey:UIApplicationLaunchOptionsURLKey]) {
        [self initUserSessionAndCallCallback:YES];
    }
}

@SamClewlow Do you have the code in your continueUserActivity and handleDeepLink? Init session depends on those methods being called when there are launch options like that. Here's the docs:

https://dev.branch.io/recipes/add_the_sdk/ios/#handle-deep-link
https://dev.branch.io/recipes/add_the_sdk/ios/#continue-user-activity

@aaustin Hi Alex,
Thanks for coming back so quickly, I find that when launching from a cold start with a deep link
- (BOOL)application:(UIApplication *)application
continueUserActivity:(NSUserActivity *)userActivity
 restorationHandler:(void (^)(NSArray *restorableObjects))restorationHandler

is never called.

It seems a new issue just now reporting the same thing. With our testbed app (in this repo https://github.com/BranchMetrics/iOS-Deferred-Deep-Linking-SDK/blob/master/Branch-TestBed/Branch-TestBed/AppDelegate.m), I'm unable to reproduce. If you're looking at the logs, you have to use the device manager instead of the Xcode terminal since it won't connect to Xcode with an externally triggered app launch.
Can you send over your app delegate code? If you don't want to post it publicly, can you start a convo with our support team at<EMAIL_ADDRESS>Sorry about the hassle!

Thanks @aaustin
I've looked into this more, and resolved the issue.
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

was returning NO (sigh), so
- (BOOL)application:(UIApplication *)application
continueUserActivity:(NSUserActivity *)userActivity
 restorationHandler:(void (^)(NSArray *restorableObjects))restorationHandler

was never called.
The issue in my case was directly returning the result of the Facebook SDK call
[[FBSDKApplicationDelegate sharedInstance] application:application
                                        didFinishLaunchingWithOptions:launchOptions];

which returns NO as the deep link is not a Facebook one.
I really appreciate your help, and hope this answer might help others experiencing similar issues!
Cheers
Sam

Have the same issue, Thanks, @SamClewlow!

@turok
Do you by any chance use the Facebook SDK? If so, do you let it handle the return statement in application:didFinishLaunchingWithOptions:?
If so, Facebook will sometimes return NO at the end of that method when a Universal Link is clicked. When it does this, it causes application:continueUserActivity:restorationHandler: to not be invoked, and then Branch fails to initialize.
If you do use the Facebook SDK in this way, please try instead changing application:didFinishLaunchingWithOptions: to always return YES. This should resolve the issue.
Alternatively, you could upgrade to the latest version of the SDK (0.11.14 or newer), then add this one line of code:
[branch accountForFacebookSDKPreventingAppLaunch];
Please let us know if this resolves the issue for you! If not, please email<EMAIL_ADDRESS>with the following:

Can you send over your implementation of application:didFinishLaunchingWithOptions:?

Please turn on setDebug (https://dev.branch.io/recipes/testing_your_integration/ios/#use-setdebug-to-simulate-fresh-installs) and send us the logs, as well as the link you're clicking. Also, be sure that you have the Branch SDK code in application:continueUserActivity:restorationHandler: (code here: https://dev.branch.io/recipes/add_the_sdk/ios/#continue-user-activity). Please also send over your code for application:openURL:sourceApplication:annotation: and application:continueUserActivity:restorationHandler: (minus any sensitive keys/code).

Hi,
I am having issue with this same thing.
I am also doing this in my application:didFinishLaunchingWithOptions: method.
return [[FBSDKApplicationDelegate sharedInstance] application:application
                                       ` `didFinishLaunchingWithOptions:launchOptions];

but as said earlier before initializing my branch session that is
branchInstance.initSessionWithLaunchOptions(launchOptions, andRegisterDeepLinkHandler: { params, error in
            if (error == nil) {
                   NSLog("params: %@", params.description)
             }
        })

I have added
branchInstance.accountForFacebookSDKPreventingAppLaunch()

But still my registerDeepLinkHandler is not working and I am not recieving any parameters.
But if I Return YES instead of
return [[FBSDKApplicationDelegate sharedInstance] application:application
                                        didFinishLaunchingWithOptions:launchOptions];

in application:didFinishLaunchingWithOptions: method its works perfectly.
Could you guys help me with this issue.
My Branch SDK version is 0.11.16.

@hammadjamal that's odd, as accountForFacebookSDKPreventingAppLaunch should properly handle this. Could you send over your code for application:didFinishLaunchingWithOptions: and application:continueUserActivity:restorationHandler: to<EMAIL_ADDRESS>Then we can take a look. If you have a sample project, all the better.

Hi, I 'm experiencing the same issue,
branchInstance.accountForFacebookSDKPreventingAppLaunch()
is not working as supposed.

Does anyone have a strong consensus/definitive on what the correct didFinishLaunchingWithOptions implementation should look like when mixing and matching Branch+FB SDK login?
Right now, I am calling Branch instance's selector accountForFacebookSDKPreventingAppLaunch, throwing out the return value of the FBSDKApplicationDelegate didFinishLaunchingWithOptions selector, initializing my Branch session (while registering a deep link handler), and then I'm always returning YES at the very end.
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [[Branch getInstance] accountForFacebookSDKPreventingAppLaunch];

    [[FBSDKApplicationDelegate sharedInstance] application:application didFinishLaunchingWithOptions:launchOptions];

    [[Branch getInstance] initSessionWithLaunchOptions:launchOptions andRegisterDeepLinkHandler:^(NSDictionary *params, NSError *error) {
        RLOGI(@"deep link data: %@", [params description]);
    }];

    return YES;
}

The documentation is a little unclear on how to do this.

Hi @TheChuckster. Sorry for the confusion. You should choose one of the following:

Always return YES;, and do not invoke [[Branch getInstance] accountForFacebookSDKPreventingAppLaunch];
Allow the Facebook SDK to determine whether application:didFinishLaunchingWithOptions: returns YES or NO, and invoke [[Branch getInstance] accountForFacebookSDKPreventingAppLaunch];

The reason for this second option is that the Facebook SDK will return NO if a Universal Link opens the app but that UL is not a Facebook UL. Some developers did not always want to modify application:didFinishLaunchingWithOptions: to always return YES, so we instead provided a way to account for that behavior.
I think you should remove [[Branch getInstance] accountForFacebookSDKPreventingAppLaunch];:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [[FBSDKApplicationDelegate sharedInstance] application:application didFinishLaunchingWithOptions:launchOptions];

    [[Branch getInstance] initSessionWithLaunchOptions:launchOptions andRegisterDeepLinkHandler:^(NSDictionary *params, NSError *error) {
        NSLog(@"deep link data: %@", [params description]);
    }];

    return YES;
}

Let us know if you have questions about this, and sorry again for the confusion.

That makes much more sense. As feedback, perhaps the documentation should mention this as well -- you explained it in a much clearer way.

@TheChuckster I added this to branch.h, thanks for the feedback!


add initial support for SOURCE_DATE_EPOCH

What this PR does / why we need it:
Adds initial support for SOURCE_DATE_EPOCH, technically this variable was already able to be injected in Dalec specs as one of the requirements to add this is to explicit require the args/envs.  It seems like SOURCE_DATE_EPOCH env var is auto injected by docker/buildx so no need to explicit --build-arg. The difference I could notice is that now with change applied the build will not fail as unknow arg for SOURCE_DATE_EPOCH var but it still requires the spec to set this variable to be used.
# syntax=ghcr.io/azure/dalec/frontend:latest
args:
  SOURCE_DATE_EPOCH: # [Required] Needs to explicit call for variable to be usable within spec

name: go-md2man
version: 2.0.3
packager: Dalec Example
...
sources:
...
build:
  env:
    SOURCE_DATE_EPOCH: ${SOURCE_DATE_EPOCH} # [Required] Needs to explicit set variable to be usable within build scope
  steps:
    - command: |
        set -x
        echo "${SOURCE_DATE_EPOCH} # If any of the required fields is missing value will be empty.
        exit 1

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):
Fixes #54
Special notes for your reviewer:

[Required] Needs to explicit call

WDYT about defining SOURCE_DATE_EPOCH by default?
The docker/dockerfile frontend doesn't do that for compatibility with existing Dockerfiles though.

@AkihiroSuda I personally prefer the explicit declaration.

After giving this some more thought, I think it would be good to not require SOURCE_DATE_EPOCH to be explicitly set in the spec.

To clarify my reasoning here, if someone wants to build a spec, they shouldn't have to modify it to get the benefits of SOURCE_DATE_EPOCH in the build itself.

Opened https://github.com/Azure/dalec/issues/447