Broken DBT 18 update on Brew ... DBT doesn't support Python 3.9

Describe the bug
This issue originally started when I merged a change into production to begin using the Shopify DBT package. The merge broke because our prod machine was still on dbt 17. So when I went to upgrade I hit the below issues.
Currently, I get the below stack trace when running dbt --version while trying to upgrade to dbt 18.1. I imagine this has something to do with my brew/python setup environment but am not quite sure exactly how to debug after about a day of brute forcing various solutions. Thanks for your help.
Steps To Reproduce

Install brew
Install Git and DBT via Brew
Run dbt --version

Expected behavior
dbt --version to return the updated version
System information
Which database are you using dbt with?

[ ] postgres
[ ] redshift
[ ] bigquery
[x] snowflake
[ ] other (specify: ____________)

The output of dbt --version:
Traceback (most recent call last):
  File "/home/linuxbrew/.linuxbrew/bin/dbt", line 33, in <module>
    sys.exit(load_entry_point('dbt-core==0.18.1', 'console_scripts', 'dbt')())
  File "/home/linuxbrew/.linuxbrew/bin/dbt", line 25, in importlib_load_entry_point
    return next(matches).load()
  File<EMAIL_ADDRESS>line 77, in load
    module = import_module(match.group('module'))
  File<EMAIL_ADDRESS>line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/home/linuxbrew/.linuxbrew/Cellar/dbt/0.18.1_1/libexec/lib/python3.9/site-packages/dbt/main.py", line 11, in <module>
    import dbt.version
  File "/home/linuxbrew/.linuxbrew/Cellar/dbt/0.18.1_1/libexec/lib/python3.9/site-packages/dbt/version.py", line 100, in <module>
    installed = get_installed_version()
  File "/home/linuxbrew/.linuxbrew/Cellar/dbt/0.18.1_1/libexec/lib/python3.9/site-packages/dbt/version.py", line 29, in get_installed_version
    return dbt.semver.VersionSpecifier.from_version_string(__version__)
  File "/home/linuxbrew/.linuxbrew/Cellar/dbt/0.18.1_1/libexec/lib/python3.9/site-packages/dbt/semver.py", line 100, in from_version_string
    return cls.from_dict(matched)
  File "/home/linuxbrew/.linuxbrew/Cellar/dbt/0.18.1_1/libexec/lib/python3.9/site-packages/hologram/__init__.py", line 618, in from_dict
    cls.validate(data)
  File "/home/linuxbrew/.linuxbrew/Cellar/dbt/0.18.1_1/libexec/lib/python3.9/site-packages/hologram/__init__.py", line 957, in validate
    schema = _validate_schema(cls)
  File "/home/linuxbrew/.linuxbrew/Cellar/dbt/0.18.1_1/libexec/lib/python3.9/site-packages/hologram/__init__.py", line 183, in _validate_schema
    schema = schema_cls.json_schema()
  File "/home/linuxbrew/.linuxbrew/Cellar/dbt/0.18.1_1/libexec/lib/python3.9/site-packages/hologram/__init__.py", line 942, in json_schema
    return cls._json_schema_recursive(
  File "/home/linuxbrew/.linuxbrew/Cellar/dbt/0.18.1_1/libexec/lib/python3.9/site-packages/hologram/__init__.py", line 913, in _json_schema_recursive
    schema = cls._schema_defs_from_cache(definitions)
  File "/home/linuxbrew/.linuxbrew/Cellar/dbt/0.18.1_1/libexec/lib/python3.9/site-packages/hologram/__init__.py", line 900, in _schema_defs_from_cache
    schema = cls._collect_json_schema(definitions)
  File "/home/linuxbrew/.linuxbrew/Cellar/dbt/0.18.1_1/libexec/lib/python3.9/site-packages/hologram/__init__.py", line 863, in _collect_json_schema
    properties[target_field], is_required = cls._get_field_schema(
  File "/home/linuxbrew/.linuxbrew/Cellar/dbt/0.18.1_1/libexec/lib/python3.9/site-packages/hologram/__init__.py", line 809, in _get_field_schema
    field_schema, required = cls._get_schema_for_type(
  File "/home/linuxbrew/.linuxbrew/Cellar/dbt/0.18.1_1/libexec/lib/python3.9/site-packages/hologram/__init__.py", line 783, in _get_schema_for_type
    raise ValidationError(f"Unable to create schema for '{type_name}'")
hologram.ValidationError: Unable to create schema for 'Optional'

The operating system you're using:
Ubuntu 18.04.5 LTS (GNU/Linux 5.4.0-1028-aws x86_64)
The output of python --version:
Python 3.9.0 (I do have multiple installs of python which may be influencing the issue)
Additional context
$ python --version
Python 3.9.0

$ brew --version
Homebrew 2.5.8
Homebrew/linuxbrew-core (git revision 071501; last commit 2020-11-03)

My best assumption is the issue lies here with the billion python installs, but not sure.
$ whereis dbt
dbt: /home/linuxbrew/.linuxbrew/bin/dbt

$ whereis python
python: /usr/bin/python3.6 /usr/bin/python3.6-config /usr/bin/python2.7 /usr/bin/python2.7-config /usr/bin/python /usr/bin/python3.6m-config /usr/bin/python3.6m /usr/lib/python3.6 /usr/lib/python3.8 /usr/lib/python2.7 /usr/lib/python3.7 /etc/python3.6 /etc/python2.7 /etc/python /usr/local/lib/python3.6 /usr/local/lib/python2.7 /usr/include/python3.6 /usr/include/python2.7 /usr/include/python3.6m /usr/share/python /home/linuxbrew/.linuxbrew/bin/python3.9 /home/linuxbrew/.linuxbrew/bin/python3.9-config /home/airflow/onedrop-scripts/transform/dbt/dbt-env/bin/python /usr/share/man/man1/python.1.gz

$ whereis brew
brew: /home/linuxbrew/.linuxbrew/bin/brew

$ which dbt
/home/linuxbrew/.linuxbrew/bin/dbt

$ which python
/usr/bin/python

$ which brew
/home/linuxbrew/.linuxbrew/bin/brew

Thank you so much

It's possible that hologram version doesn't support Python 3.9. There were some changes in a recent hologram commit to support 3.9, but it hasn't been packaged yet and dbt support for 3.9 hasn't been done yet.

Thanks, you're right. Resolved via instructions in this thread to use pip3 instead of brew: https://getdbt.slack.com/archives/C2JRRQDTL/p1594318582280200?thread_ts=1594253045.233300&cid=C2JRRQDTL

Experimenting the same bug inside a GitHub Action (python 3.9).
@lucaswiley can you provide instructions on how to solve here (without having to log in to Slack) ? Thank you.
      - name: Setup Python
        uses<EMAIL_ADDRESS>
      - name: Setup dbt
      - run: |
          pip install dbt
          dbt --version

There are broken dependencies on the DBT brew installation for Python 3.9. Instead use pip3:
brew remove dbt
pip3 install virtualenv virtualenvwrapper
virtualenv foo
pip3 install dbt

I am using Conda and this is what I did to resolve this issue.
Downgrade python from 3.9 to 3.8:
conda install python=3.8

Do a force reinstall of dbt:
pip3 install --upgrade --force-reinstall dbt

Run dbt --version:
(dbt-poc) ➜  dbt-poc git:(master) dbt --version
installed version: 0.18.1
   latest version: 0.18.1

Up to date!

Plugins:
  - bigquery: 0.18.1
  - snowflake: 0.18.1
  - redshift: 0.18.1
  - postgres: 0.18.1

This bug hasn't been solved, please reopen the ticket.

The latest version of dbt (v0.18.1) does not support python 3.9. We plan to add py39 support (#2822) for the next release of dbt (v0.19.0). If it proves straightforward, I'd also like to release a patch version (v0.18.2) that is compatible with python 3.9 as well.
In the meantime, I am going to close this issue as a duplicate of #2822.

Hello, I still have this issue with sqlfluff, dbt 0.19 and python 3.9
pip3 --version
pip 21.1.1 from /usr/local/lib/python3.9/site-packages/pip (python 3.9)
python3 --version
Python 3.9.4
dbt --version
installed version: 0.19.1
sqlfluff --version
sqlfluff, version 0.5.6
When running sqlfluff lint with templater = dbt. WHen I remove template = dbt it runs, but jinja seems to be broken. Is that to be expected ?

Hey @Startouf, dbt-core==0.19.1 is compatible with py39, but one of the plugins included by pip install dbt (dbt-snowflake==0.19.1) is not compatible with py39. The next minor version (v0.20) will be.
I'm not positive if that clarifies the jinja issue you're seeing, but suffice to say, it is expected that pip install dbt==0.19.1 + py39 don't yet work together. If you know which adapter you're using, however, and it isn't Snowflake, you can install that in a py39 environment just fine, e.g. pip install dbt-postgres.

confirmed this works in a clean py39 env
pip install dbt-postgres==0.19.1
dbt --version

Still encountering this issue for 0.19.1 with a fresh dbt install on Arch Linux and python 3.9. Creating a virtualenv with 3.7 fixed it for me.


Error when starting "Start Stable-Diffusion" while "fast_stable_diffusion" is running　etc...

When I started "Start Stable-Diffusion" at the bottom while "fast_stable_diffusion" was running, the following message appeared. Please let me know what to do.

ModuleNotFoundError                       Traceback (most recent call last)
 in <cell line: 6>()
4 import sys
5 import fileinput
----> 6 from pyngrok import ngrok, conf
7 import re
8
ModuleNotFoundError: No module named 'pyngrok'

NOTE: If your import is failing due to a missing package, you can
manually install dependencies using either !pip or !apt.
To view examples of installing some common dependencies, click the
"Open Examples" button below.
I mentioned earlier that "Restart Runtime" -> "Disconnect and Delete Runtime" solved the problem, but sometimes the resulting image turns red. Please let me know what I should do.

Repaired.
It appears to have been a temporary error.
Thank you very much.


Adjust the error message for disallowed bound name

Fixes #1558

Current coverage is 100% (diff: 100%)

Merging #1559 into master will not change coverage

@@           master   #1559   diff @@
=====================================
  Files           1       1
  Lines        3732    3732
  Methods         0       0
  Messages        0       0
  Branches      628     628
=====================================
  Hits         3732    3732
  Misses          0       0
  Partials        0       0

Powered by Codecov. Last update 89f4ed5...de36274

:+1:


API Pull request URL returns JSON

The API URL that is trying to specify YAML for the pull-request command actually gets back JSON from the API which results in a failed parsing of the response. The pull request is successfully created though.

Shouldn't you open a bug about this with GitHub?


Package dependency ranges not supported

Type: Bug
NPE version: 3.14
Installed from: ClickOnce

What is the current result?
When adding a package dependency, version ranges like "[4.0.0-5.0.0)" are disallowed

What is the expected result?
These ranges are valid for Nuget packages and should be allowed.

Please post full exception details in case of an Exception (message, stacktrace, inner exceptions)
No exception occurs.

Are there any work arrounds?
no

Is there a version in which it did worked?
Unknown

Is there a package on Nuget.org which shows the bug?
No.

Can you post a screenshot or give a package so we can easily reproduce?

bump

Sorry.  Been distracted.

ah thanks! This makes things more clear :)

Hang on.. went to nuget site for docs.  syntax uses commas...
Commas work.

Maybe support for interpreting a hyphen and changing to a comma automatically.  Other than that, I think this should be closed as a non-bug.

:+1: thanks for testing.


Incorrect handling of 'preferred' user verification.

Specifically, it is handling 'preferred' as 'required'.
By my reading of the Webauthn spec, the handling of 'preferred' depends of the definition of 'Protected by some form of User Verification'.
Per the spec, this requires that the support be both supported and enabled.
In 6.1.1, the text at the beginning describes the case where user verification is 'required' and not present.
It then describes the process flow, I draw some attention to 6.1.1, 1.1 where things start to go wrong in the described flow, though I will definitely note that the text at the beginning says 'In other words, this is only a brief sketch of plausible platform behavior.'

If the authenticator is protected by some form of user verification, or the Relying Party prefers enforcing user verification (e.g., by setting options.authenticatorSelection.userVerification to "required", or "preferred" in the WebAuthn API

In 6.1.1, <IP_ADDRESS> we get to the point where the code is following the described flow...  But the described flow simply does not handle this case.
The request says that user verification is 'preferred', the device has support for clientpin, however clientpin is not configured on the device.
This is currently handled in fido2/client.py, class _Ctap2ClientBackend, function _should_use_uv, on line 470.
In this code, it looks at both if uv is supported, and if uv is configured.
If user verification is REQUIRED, or if user verification is preferred and supported, or if 'alwaysUv' is set by the device, then it fails if uv is not configured for the device.
I propose that the uv_supported check be removed entirely, and in the if statement we replace:
            or (
                user_verification == UserVerificationRequirement.PREFERRED
                and uv_supported
            )

with
            or (
                user_verification == UserVerificationRequirement.PREFERRED
                and uv_configured
            )

This would, I believe, be both compliant to the spec, and would work for the fairly common case where user verification is preferred, but not required, and a user with a Yubikey 5 has not configured a PIN.

See my comment here: https://github.com/Yubico/python-fido2/pull/148#issuecomment-1253569638
IMO the spec isn't completely clear as to the correct behavior, but the behavior we have implemented is (I believe) in line with what the major platforms are doing.

@dainnilsson
I agree that the spec could be more clear as to the correct behavior here.
However I disagree that the current behavior is sensible, preferred should use UV if it is readily available, and still work regardless.
So, I did a little digging.
And the current behavior is definitely not how either Firefox or Chrome behave.
I did some quick hunting for a for Webauthn demos that allow you to specify the user verification setting, and found:
https://webauthn.singularkey.com/
This works on both Chrome and Firefox.
With User Verification set to Unspecified, Discouraged, or Preferred, my Yubikey 5 with no PIN set is accepted by both Firefox and Chrome.
With User Verification set to Required, Firefox simply ignores the Yubikey as not being a qualified device, while Chrome prompts for me to setup a PIN.

@zelch Thanks - you may be right, but the CTAP2 spec is currently underspecified in regards to this.
Some background: We had misremembered the WebAuthn spec saying this about the "preferred" case:

[...] user agents SHOULD guide the user through setting up user verification if needed to create a client-side discoverable credential in this case.

...and that that is how Chrome behaves.
However, that is only true for residentKey: "preferred", not userVerification: "preferred". The latter only says:

This value indicates that the Relying Party prefers user verification for the operation if possible, but will not fail the operation if the response does not have the UV flag set.

and Chrome indeed does not prompt the user to set a PIN if one is not currently configured.
So yes, from a WebAuthn Relying Party perspective, the ceremony should indeed proceed without requiring the user to set up a PIN.
However...
The python-fido2 feature discussed here is part of the client-facing library, not the RP-facing library. It's quite reasonable that a client implementation should be able to detect whether a PIN is set or not, and decide whether or not to prompt the user to set one up. Unlike an RP, a client can catch the exception, decide how to proceed, and adjust the make_credential() arguments as necessary, without having to cause a user interaction during that process.
There is support for this interpretation in the CTAP2 spec you linked, too. If the RP has set userVerification: "preferred", the procedure enters step 1.1., and there is no path out of that branch that results in an authenticator response without UV. That might require the user to set up a PIN, so the client implementation should be able to do that, but it's not appropriate for the library to try to do it internally. The calling application should be in control of any user interaction, so the library raises an exception to return control to the caller.
However...
There is a logical inconsistency in the CTAP2 spec. Step 1.1. reads:

If the authenticator is protected by some form of user verification, or the Relying Party prefers enforcing user verification (e.g., by setting options.authenticatorSelection.userVerification to "required", or "preferred" in the WebAuthn API):

and step 1.2., which should be its logical complement, reads:

Otherwise, implying the authenticator is not presently protected by some form of user verification, or the Relying Party wants to create a non-discoverable credential and not require user verification (e.g., by setting options.authenticatorSelection.userVerification to "discouraged" in the WebAuthn API), [...]

But these two statements are not logically complementary - for that, the latter should rather read "[...] AND the Relying Party [...]". Perhaps the "preferred" case should also be moved from the example in 1.1. to the example in 1.2. Because strictly speaking, there is currently a gray area where both conditions apply: when the authenticator does not have a PIN set, but the RP has set userVerification: "preferred" or "required".
I'll raise an issue in the CTAP spec about clarifying this. But for now, I don't think we can conclude that the current implementation in python-fido2 is incorrect.
What do you think?


"calculate" is missing

It seems the "calculate" icon is missing.

I made A PR https://github.com/jossef/material-design-icons-iconfont/pull/68


Is there a best way to use a global httpclient but with a different timeout setting per request?

Is there a way to add a timeout setting for per request if i declare a global var? Because in my case i need different timeout setting for per request.Currently i am doing it with creating a new client object for per request:
func getTiemoutClient(timeout int) *http.Client {
     client := &http.Client{
		Timeout: time.Duration(timeout) * time.Millisecond,
	}
        return client
}

is this a better way ?
func Do(ctx context.Context, client *http.Client, req *http.Request) (*http.Response, error) {
    if client == nil {
        client = http.DefaultClient
    }
    resp, err := client.Do(req.WithContext(ctx))
    // If we got an error, and the context has been canceled,
    // the context's error is probably more useful.
    if err != nil {
        select {
        case <-ctx.Done():
            err = ctx.Err()
        default:
        }
    }
    return resp, err
}

For questions about Go, see https://golang.org/wiki/Questions.


Tweaks on Reset option

@keybase/react-hackers
@malgorithms @buoyad I changed it so that the Reset button is there right away:

The commits 0afb68ae4761...9353a2573019 introduce visual changes on linux. :mag_right: 2 changed

Changed: Select_Other_Device-Normal (before) (after)

Changed: Select_Other_Device-No_User_Pass_Login (before) (after)

looks good to me

Maybe could be blue or green or something so it doesn’t look like main CTA on the screen?

I like that it feels dangerous, even if it does draw attention. but ok no matter what

sounds good

@MarcoPolo I actually changed the button to be a red link (less in your way). Need approval again, thanks!

The commits 0afb68ae4761...287d53a882be introduce visual changes on linux. :mag_right: 2 changed

Changed: Select_Other_Device-Normal (before) (after)

Changed: Select_Other_Device-No_User_Pass_Login (before) (after)


remove ros2_ouster_drivers entry from rolling in preparation for replacing with the official ouster_ros package.

Please remove the following dependency to the rosdep database.
Package name:
ros2_ouster_drivers
Package Upstream Source:
https://github.com/ros-drivers/ros2_ouster_drivers
Purpose of using this:
Remove ros2_ouster_drivers entry from rolling in preparation for replacing with the official ouster_ros packages.
Distro packaging links:
Links to Distribution Packageshttps://github.com/ros-drivers/ros2_ouster_drivers
Comments to reviewers
I will have a followup pull request to add an entry to the rolling distribution list once this has been removed since bloom wouldn't allow me to create a pull request due to package name conflict for ouster_msgs.
I have already prepared the rolling release: https://github.com/ros2-gbp/ouster-ros-release
Should I manually add ouster-ros entry in this pull request? Let me know please...

The followup PR would be same as https://github.com/ros/rosdistro/pull/38390 but targeting rolling

I'm not sure what the ramifications might be of moving a single package from one release entry to another... maybe it'll be fine?   @nuclearsandwich I could use some more expert input on what might happen here.

@emersonknapp or @nuclearsandwich how could we move this forward?

I think removing the older package first will be the best; then you can do the normal bloom-release process.  Before we do that, though, this needs to come out of draft and I would like explicit confirmation from @SteveMacenski that this is the right path forward.

I did put it in Draft mode for now as we are trying to make a decision between converging the official ouster-ros with ros2_ouster_driver package and move it into ros-drivers org, or keep the two packages totally separate (i.e. ouster-ros to totally replace ros2_ouster_driver entry within rosdistro starting with rolling/iron) . and yes I am in talks with @SteveMacenski about this move. We should reach the decision within this week.

I'm not sure what the ramifications might be of moving a single package from one release entry to another... maybe it'll be fine?

At the very least, breaking all existing users since those messages I assume aren't exactly identical.

this needs to come out of draft and I would like explicit confirmation from @SteveMacenski that this is the right path forward.

I don't agree with this action until the comment below is resolved. I don't know why @Samahu is rushing this process, we should pause and not make any more moves until you have clarity from your management.

we are trying to make a decision between converging the official ouster-ros with ros2_ouster_driver package and move it into ros-drivers org, or keep the two packages totally separate

@SteveMacenski I don't think I am rushing this process, I created this MR over a week ago when I found about the name conflict with 'ouster-msgs' and that bloom-release blocked it. I put this MR in Draft mode on Friday in order to take time to research the subject a bit more and discuss with management about which path they would prefer. Although I play a role in the decision but it is definitely not entirely up to me and I need to act in the interest of Ouster and what suits the company better short and long term.
With regard to message breaking changing, this would only affect the rolling distro and as far as I know developers on rolling do expect some breaking changes to happen while on this distro.

Holding for an upcoming Rolling sync

@SteveMacenski We have discussed this internally and for the time being Ouster would like to keep ouster-ros driver fully under ouster-lidar organization.

@SteveMacenski still waiting for your approve.. why is this taking so long?

OK, in that case, you will need to rename your package. The following are already used names and I will likely re-release under them for Iron since we're not merging into the ros-drivers repository. If its going to continue to live on, it should be available for users under the binary format as it has been historically. Think of them now as community-supported drivers. This is not the direction I wanted to go, I wanted to remove them and replace with your company-supported version, but if they're just hanging around, then status quo should continue for those that rely on it.
So no, I think this PR should be closed and I can sync up with an Iron release of these packages after ROSCon
      - ouster_msgs
      - ros2_ouster

OK, in that case, you will need to rename your package. The following are already used names and I will likely re-release under them for Iron since we're not merging into the ros-drivers repository. If its going to continue to live on, it should be available for users under the binary format as it has been historically. Think of them now as community-supported drivers. This is not the direction I wanted to go, I wanted to remove them and replace with your company-supported version, but if they're just hanging around, then status quo should continue for those that rely on it.
So no, I think this PR should be closed and I can sync up with an Iron release of these packages after ROSCon
      - ouster_msgs
      - ros2_ouster

I don't know where to start, I am really dismayed by your response. What kind of direction you wanted? I mean previously you asked me to clarify the decision if Ouster wants to merge the source code with your driver? I had discussed this thoroughly with the management here at Ouster, the decision was clearly irrevocably to not merge the official driver with ros2_ouster_ros repo for an array of reasons. One of the reasons we decided to not merge with ros2_ouster_ros repo is to avoid the the headache that you mentioned going forward and have one source of reference for the driver that our users can refer. We don't prevent anyone from re-using whole or part of our code to create their own implementation but at the same time we'd like to retain the official implementation fully under ouster-lidar organization. At the request of many of our users we worked on providing a binary release of the official driver through ROS distribution, which has been done for Iron release and the same should happen for ros-rolling.
Now that the company has clarified its position you decided to regress on your part and hold off approving this PR? Why did you ask me to check with the management about our decision when you had no intention of supporting the decision of the company?
The rolling distro is for development, users who are consuming your implementation on galactic, foxy, humble wouldn't be affected by this change. Users who wish to retain access to the binaries published to these previous distros, I am not planning to submit a PR to change them.
In the last e-mail you sent me you mentioned that you have been supporting Ouster the entire time but now I am reading your response and I am not sure how this fits? How does disallowing our company from providing binary distribution of the official driver through ROS but at the same time allowing others to take over and publish a binary distribution for the driver with a package name that includes the name of the company, how does help serve Ouster users and how does this not going to continue be a source of headache for us and for our users?

This pull request has been mentioned on ROS Discourse. There might be relevant details there:
https://discourse.ros.org/t/who-has-the-first-right-to-publish-binary-package-using-the-companys-name/34200/4

The discourse thread led me here. I see it is a pretty complicated issue to resolve. What about naming the manufacturer driver packages ouster_official_*? That would resolve all naming conflicts and users would right away know they are using the official driver.

But the depreciation of this work was under the explicit agreement that your new work would be replacing this driver. Since that is no longer happening, this software is going to remain because its not being overwritten anymore.

What is this explicit agreement exactly? In a way this PR is in fact replacing the ros2_ouster_driver.. but I don't remember personally that I agreed (or Ouster) to having to move or merge ouster-ros code into ros2_ouster_driver. It is very problematic on multiple fronts for us to do so.

s ouster_official_*? That would resolve all naming conflicts and users would right away know they are using the official driver.

Thanks Martin but is this a common pattern? I searched ros index and didn't find a single package that uses the word  official.. into the name. ouster_msgs seems the the most fitting given that Ouster originally (before I joined them) named the main package as ouster_ros.
Still reviewing the community opinion about this and I am hoping we can get past this soon.

My understanding of the problem is that it is only the ouster_msgs package that conflicts. I'd like to encourage both sides to find a way to use the same messages for their respective drivers. This would improve the user experience by allowing the user to choose which driver implementation meets their needs without needing to make changes to the rest of their system.

I suppose one option is to sunset the existing driver, but I will need to put out a call for that and wait for responses from users that the new driver is sufficient for their needs before I pull the rug from under them. That may take several months but I can start the inquiry after ROSCon.

Yes please! It's likely folks have the older driver baked into things, suddenly pulling it would impact folks, including us.

Thanks all for your valuable feedback, sorry for being slow on this matter but I have on a PTO this past time. I am waiting for a confirmation on the path the company wants to take before moving forward but we should conclude this PR soon.

After discussing this matter with Ouster management we decided to rename "ouster_msgs" package part of the official driver to "ouster_sensor_msgs" to avoid this conflict. As such I am closing this PR and will open another one soon after the name change is applied.


docs: fix bigquery.md

@Eraac thanks for the PR, please merge the latest master as tests were broken and need to pass before I merge your PR


feat: create a increase_day_index function

[x] issue #15
[ ] follows contribution guide
[ ] code change includes tests
[ ] breaking change

This PR implements an increase_day_index function to increment a day_index variable in storage each time 24h have passed.
Closes #15

@b-j-roberts Hi, here is a first draft.
I need more precisions about the purpose of this function. For now, i created an internal impl for this function, as i guess this function will be called internally each time a user interacts? Or is there any backend in charge of calling it externally by an admin ? or anyone?
Currently, the function will reset a new start day , setting the current block timestamp as a new start day time. This means that if the function is called more than each 24h exactly, each incrementation will not correspond to 24h exactly. I can modify it to make sure each index is 24h by setting the new start value to the last one + 24h
I will add tests once i fully understand how this function will be used!

Hey, good work and nice points @TAdev0 !
I think having the function callable externally by anyone is good and decreases the need for trusting an admin. We will need to add an assert that prevents increasing the day index until enough time has passed though.
However, we will do the increase_day_index calls ourselves when the app is live, to make a smooth user experience.
For the "exact timing" issue, I think it's fine if each day goes longer than 24h exactly. However, it's up to you. Either have it set the new start time like it is now, or set the new start time to exactly start time + 24h, whatever you think is best!
Side note: You can set the initial start time in the constructor to be equal to creation time

@b-j-roberts  thanks for the quick answer.
True i forgot to initialise the initial the start_day_time value, my bad.
well it's up to you:

If you want a fix 24h period, i can change it. This will also mean that if nobody calls the function during multiple days, it will be possible to call it multiple time in a row to be up to date and catch the current real index day.

if we keep this, index will increase only by one  once you call again the function

@b-j-roberts thanks for the quick answer. True i forgot to initialise the initial the start_day_time value, my bad.
well it's up to you:

If you want a fix 24h period, i can change it. This will also mean that if nobody calls the function during multiple days, it will be possible to call it multiple time in a row to be up to date and catch the current real index day.
if we keep this, index will increase only by one  once you call again the function

Yeah, based on the way Starknet works, I don't think there is a perfect solution for time based things like this sadly.
The trade-off with switching to an exact 24-hour period that allows multiple calls to catch up is that if that is done, people wouldn't have the opportunity to complete the quests on the skipped days.
So there will be something lost either way. Let's keep it how you have it now, unless you would really prefer the other option.
You can add the tests for the current implementation.

oh yeah i see, indeed if you want each day index to be a period where people have the opportunity to complete quests we should keep it like this.

@b-j-roberts  just added 2 tests !


Support for Visual Studio Team Services

Please can support for Visual Studio Team Services be adsed to Read the Docs? This is the only thing that is stopping us from adopting the platform for our documentation.
If this is already in the pipeline, when is the expected release date for this feature?

This issue is being marked as Community Effort. The core team will try to facilitate resolution with this issue, but without the resources to support external installations outside of our production environment, we must rely on the community to help.
You can read more information on our philosophy around supporting Read the Docs as an open source and volunteer run effort here: http://docs.readthedocs.io/en/latest/open-source-philosophy.html

If I wanted to start working on this integration, as a contributor - what support could i receive and who would I need to contact to get the ball rolling?

Let's ask @ericholscher and @agjohnson about this.

@martinfletcher There would be two pieces, the integration here, and the integration with django-allauth, if it doesn't already exist. We use allauth to provide authentication and oauth capabilities with external APIs. This is probably a good place to start.
After that, there are a number of pieces that RTD needs. #1870 is a mostly complete example here, but that PR has been around long enough that a few things have changed. Our webhook pattern has changed completely and I'm working on a few other pieces that would need to be added with the GitLab and VSTS integrations. Still, this is a good example to base requirements off of.
As for how to get started, I can lay out a ticket that would explain the requirements for development. We can either collaborate there, or IRC is always a good place to get realtime-ish help.
I haven't looked much into VSTS's API capabilities, but I think expanding out to other providers makes a lot of sense. As long as we can create webhooks that would be fired off on commit/other events and can designate private keys through the API, we can likely support the platform. We'd love to have help here, as I've never used VSTS, and it likely wouldn't be on our roadmap anytime soon.

My primary question is, what does integration look like? If you only need to build your documentation on commit, you can also do that pretty easily on your own. Ironically our build API isn't well documented, but if that is the only requirement, that might be the shortest path.

Hey @agjohnson and @martinfletcher! Is that any progression in that issue? Do you need any help? I'd like to contribute on fixing this issue.

Hi @joaobentes - I have not had much free time in the past 12 months due to projects and moving jobs.
This is still something that i would like to get stuck into though!
@agjohnson for me an issue on GitHub, or a slack channel would be the best means of collaboration. My python skills are a tad rusty, but would be able to gen-up quite quickly, and i know how the VSTS product works very well.

We still don't have a lot of resources to allocate to an integration like this. I'm not familiar with VSTS, but as long as you can get an SSH Git URL to a public repository, you can attach this repository to a RTD project. The integration isn't as nice, and isn't one-click setup, but it works. It also requires manual set up of a webhook -- you can set up a generic webhook integration on your RTD project, and point VSTS at this hopefully.
If this is enough, perhaps we just need some documentation on using unsupported providers like VSTS, Visual Studio Online, etc.


Improve orttrainer test

What does this PR do?

[ ] Improve ORTTrainer test.
[x] Improve ORTTrainer test triggering.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

Current constraint, we won't be abled to launch GPU test and ORTTrainer test at the same time, as the workflow will

launch both GPU and ORTTrainer tests when adding a label.
check the name if not correct skip it immediately

This means that when adding a new label if the previous running test triggered by label is not finished, it will be relaunched and skipped.
As in our use case, we rarely see cases in which we need to check both tests. And even if we do, we can wait for one to finish before launching the other. So I guess it would be fine.

Need to update the CI with onnxruntime 1.14.0 as older numpy has been unpined
AttributeError: module 'numpy' has no attribute 'bool'.
`np.bool` was a deprecated alias for the builtin `bool`. To avoid this error in existing code, use `bool` by itself. Doing this will not modify any behavior and is safe. If you specifically wanted the numpy scalar type, use `np.bool_` here.
The aliases was originally deprecated in NumPy 1.20; for more details and guidance see the original release note at:
    https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations

A PR will be opened to update ORT training dockerfile.


Detect $77 process in python ?

Hello
I'm working on a monitoring and watchdog system in Python, and I need to detect processes that are hidden by the r77 rootkit. This rootkit uses advanced techniques to conceal certain processes, making standard monitoring tools ineffective.
My goal is straightforward: I want to write a Python script that can list all currently running processes, including those hidden by the r77 rootkit, without using the rootkit's Test Console.
Here's what challenges me:
The rootkit uses hooks and a "control pipe" for interactions, which hides processes from typical system queries.
I need a way to bypass or emulate the functionality of the rootkit's Test Console, which is capable of listing these hidden processes.

Questions:
How can I access in Python to detect hidden processes?

After thorough investigation and experimentation, I've discovered two viable approaches to interact with the r77 rootkit in a way that allows a Python script to list processes hidden by the rootkit. Here are the details of each method:
Compiling Python Script into an Executable with a Helper Signature:
    The first approach involves compiling the Python script into an executable using tools like PyInstaller. After the script is compiled, modify the binary to include the R77HelperSignature (0x7268). This signature marks the executable as a "helper" process. According to the r77 rootkit's documentation, it does not inject into helper processes. By incorporating this signature into the executable, the Python script is effectively shielded from rootkit injections, ensuring it runs without interference.

Using the $77 Prefix:
    The second method is also based on compiling the Python script into an executable. However, instead of modifying the signature post-compilation, this approach involves naming the executable with the $77 prefix, which is recognized by the rootkit as a signal to avoid injection. By naming the compiled Python executable with this prefix, the rootkit automatically excludes it from its injection processes. This allows the script to operate normally and list all processes, including those hidden by the rootkit.

Hello! I know this issue is already closed but I wanted to give one more option based on my experience.
So another potential solution to consider is to continuously unload the R77 DLL file from the watchdog system by checking modules on the process. This approach is based on the observation that the R77 rootkit appears to inject processes automatically only when they are created. By regularly unloading the DLL, you might be able to prevent the rootkit from injecting its code into newly spawned processes, thereby allowing you to detect and list them without interference.


[Snyk] Upgrade openai from 4.24.2 to 4.26.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade openai from 4.24.2 to 4.26.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 7 versions ahead of your current version.
The recommended version was released 23 days ago, on 2024-01-25.

Release notes

Package name: openai

4.26.0 - 2024-01-254.26.0 (2024-01-25)
Full Changelog: v4.25.0...v4.26.0
Features

api: add text embeddings dimensions param (#650) (1b5a977)

Chores

internal: add internal helpers & improve build scripts (#643) (9392f50)
internal: adjust ecosystem-tests logging in CI (#646) (156084b)
internal: don't re-export streaming type (#648) (4c4be94)
internal: fix binary files (#645) (e1fbc39)
internal: minor streaming updates (#647) (2f073e4)
internal: pin deno version (#649) (7e4b903)

4.25.0 - 2024-01-214.25.0 (2024-01-21)
Full Changelog: v4.24.7...v4.25.0
Features

api: add usage to runs and run steps (#640) (3caa416)

Bug Fixes

allow body type in RequestOptions to be null (#637) (c4f8a36)
handle system_fingerprint in streaming helpers (#636) (f273530)
types: accept undefined for optional client options (#635) (e48cd57)

Chores

internal: debug logging for retries; speculative retry-after-ms support (#633) (fd64971)
internal: update comment (#631) (e109d40)

4.24.7 - 2024-01-134.24.7 (2024-01-13)
Full Changelog: v4.24.6...v4.24.7
Chores

ecosystem-tests: fix flaky vercel-edge, cloudflare-worker, and deno tests (#626) (ae412a5)
ecosystem-tests: fix typo in deno test (#628) (048ec94)

4.24.6 - 2024-01-124.24.6 (2024-01-12)
Full Changelog: v4.24.5...v4.24.6
Chores

ecosystem-tests: fix flaky tests and remove fine tuning calls (#623) (258d79f)
ecosystem-tests: fix flaky tests and remove fine tuning calls (#625) (58e5fd8)

4.24.5 - 2024-01-124.24.5 (2024-01-12)
Full Changelog: v4.24.4...v4.24.5
Refactors

api: remove deprecated endpoints (#621) (2054d71)

4.24.4 - 2024-01-124.24.4 (2024-01-11)
Full Changelog: v4.24.3...v4.24.4
Chores

internal: narrow type into stringifyQuery (#619) (88fb9cd)

4.24.3 - 2024-01-104.24.3 (2024-01-10)
Full Changelog: v4.24.2...v4.24.3
Bug Fixes

use default base url if BASE_URL env var is blank (#615) (a27ad3d)

4.24.2 - 2024-01-094.24.2 (2024-01-08)
Full Changelog: v4.24.1...v4.24.2
Bug Fixes

headers: always send lowercase headers and strip undefined (BREAKING in rare cases) (#608) (4ea159f)

Chores

add .keep files for examples and custom code directories (#612) (5e0f733)
internal: bump license (#605) (045ee74)
internal: improve type signatures (#609) (e1ccc82)

Documentation

fix docstring typos (#600) (1934fa1)
improve audio example to show how to stream to a file (#598) (e950ad9)

    from openai GitHub release notes

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Working on my recent pull request I already updated OpenAI to v 4.28.0:
https://github.com/OpenPipe/OpenPipe/pull/599

Fixed in https://github.com/OpenPipe/OpenPipe/pull/599


Introduce organizations (user groups) for full multi-tenancy

Organizations (or groups of users) should be introduced to enable full multi-tenancy.
Admin account equally should be introduced:

Admin of the organization
Admin of the whole Mainflux system (admin of admins)

Related to https://github.com/mainflux/mainflux/issues/397

We should investigate if it would be possible to use some 3rd party identity management (IAM) that would handle multi-tenancy and user rights and roles. Each user entity in the 3rd party IAM would be connected with one user in the mainflux core and IAM would keep that relation. When authenticated against 3rd party IAM request would be forwarded with information about mainflux user, probably in the header.
Some of the features, like admin access, might be controlled with api gateway which would rely on used IAM

@mteodor this is eaxctly how Hydra is working: https://www.ory.sh/docs/ecosystem/overview - a requests are inercepted by Oathkeeper proxy, which acts as a Policy Enforcement Point (PEP). Requests are then forwarded to Keto, which acts as a Policy Decision Point (PDP) (more on terminology here).
XACML and SAML can be used for this purpose.
Keto is very interesting, as it uses OPA. Regarding from this issue: https://github.com/ory/keto/issues/47, they depricated Ladon and moved on with OPA.

Interesting blog regarding OPA and policies: https://blog.verygoodsecurity.com/posts/building-a-fine-grained-permission-system-in-a-distributed-environment/

References for research and study:
https://blog.verygoodsecurity.com/posts/building-a-fine-grained-permission-system-in-a-distributed-environment/
https://www.openpolicyagent.org/
https://www.ory.sh/docs/ecosystem/overview
https://github.com/ory/keto/issues/3
https://ccskguide.org/policy-decision-points-policy-enforcement-points/
https://github.com/summerwind/opa-nginx-rbac
https://github.com/cloudflare/cfssl
https://en.wikipedia.org/wiki/XACML
https://en.wikipedia.org/wiki/SAML_2.0
https://en.wikipedia.org/wiki/Attribute-based_access_control
https://en.wikipedia.org/wiki/Role-based_access_control
https://www.youtube.com/watch?v=XEHeexPpgrA

Could we please first define what are the requirements and how will everything be organized before we choose the implementation method and tools?
At the moment all the things are owned by a user.
The way I see the restructuring to organizations:

each organization can have sub-organizations or member users
each organization have admin users which can add/remove users and sub-organizations
each organization owns things (devices) which can be assigned to users
each user can own a thing (device). This would be useful in case of BYOD (Bring Your Own Device) scenarios.
access rights read/write to a thing (device) can be given per thing class. The things will be grouped  For i.e. a temperature analysis app would have read access to all temperature sensors in an area
access rights read/write can be added to a single thing instance

Questions:

How are we going to manage the things? Will they be owned by an organization or a user?
How are we going to propagate the permissions? Will the child org inherit the permissions of the parent org and can overwrite them?
One can send multiple measurements for different properties in a single SenML message. At the moment the only way to specify thing properties is via the metadata. Do we need create an extra ThingProperty entity, so that we can have fine grained access to a thing property? This can be useful if we have sensors which measure different physical properties and we want to control which property can be accessed by which app.
What would happen if we want to share data across organizations? A practical example would be when an organization buys many sensors and hires a maintenance company to monitor and repair the sensors. The maintenance company might need to read some status/monitoring data to check the state of the sensors.

@mainflux/contributors what are your thoughts on this?

I fully agree with @chombium. We are missing requirements and concepts.
I'm least concerned about the tech/tooling part.
We agreed to continue the discussion here.
I like your points @chombium but also concerns, right questions.
First, I would like to pick your brains on this access control topic because I think it will move your minds in other directions.
What if we can keep everything as is, the only user owns the device, there are no multiple user roles in the system (I don't think we need it), etc... and introduce ABAC policies.
Let's stick with organizations/groups first. For the sake of simplicity, let's call it a group.
IMHO Group is a new entity in Mainflux, which class any other objects with the same type (user, things, channels).
Example Group structure:
type Group structure {
  type: int // We can have predefined group types that we support with iota
  objects: []string // UUID's of grouped objects with same type (users, things ,channels)
  metadata: map[string]interface{} // For your custom stuff , name description etc... its user defined.
}

As you can see, it's lean and simple with only one purpose, to group/class the objects of the same type (technically it would be complicated to group objects with different types, and I am pretty sure we should NOT mix it).
Back to ABAC policies.
Any entity in Mainflux is an attribute (user, thing, channel, group), represented by its UUID. Following this logic, we can create a policy with read/write permissions to any attribute. The policy should answer to question:
Who can/cannot perform action X on attribute Y.
Take a messaging, for example. We have a thing which can pub/sub to channel. Policy would define
Thing can/cannot pub/sub on channel X
Or
User can/cannot view/edit group X
Or
User can/cannot view/edit thing X
Or
User can/cannot view/edit user X
Or
Group can/cannot view/edit attribute X
Etc...
The tricky part is when a subject (in policy terminology an entity that wants to perform an action) has multiple policies, like at the same time, its a member of N groups with different permissions.
But this is more a question of tech/tools and impl.
As described in  access control issue, I did research regarding technology/tools, and currently, my favorite is Casbin library, doing some code spikes to verify the idea ^
I think such a generic approach where you have the flexibility to design your access control will cover most use cases. That policy logic can be placed in new AuthZ service which will expose both gRPC (internal use) and HTTP API (publicy use), but this is again a question for impl, let's leave it for #later.
One more thing to consider is, Do we need channels then? Do we need to connect things if we have groups and policy management?
let me know your thoughts @mainflux/contributors

I think that ABAC policies are the right way to go. Also, I agree that groups should be really simple as you suggested (have just ID and metadata).

One more thing to consider is, Do we need channels then? Do we need to connect things if we have groups and policy management?

This will change a lot of things regarding MF. I think that we can develop a solution that doesn't need a chan ID. Instead of connecting to the channel, we can say in the policy: this group has access to this topic and all of its subtopics. And that's it. Then you can have really generic solution with fine-grained access control.

@anovakovic01 Fully agree, let's remove everything we don't need in channels regarding to access control (e.g connections) and keep just things that we need for messaging like topics, metadata, etc...

@nmarcetic fully agree for the groups - lean and make sense.
I also prefer ABAC approach.
Channels are groups, a poor-man's communication or permission gorups.

Instead of connecting to the channel, we can say in the policy: this group has access to this topic and all of its subtopics.

True - insterting a thing into a group that has a permission to write to a certain channel is indeed same as connecting it to a channel.
With full-blown access control mechanism channels should become obsolete.

I think that we can develop a solution that doesn't need a chan ID

We neet to think how we will represent a topic, as channel is an abstraction over MQTT topic, REST URL, CoAP URL and WS.

@drasko, @nmarcetic, @anovakovic01 I fully agree with all of you when we are talking about the data flows and who has access to which data.
What are we going to do about managing the thing and the CRUD operations on them? Are we still going to say that all of the things are owned by a single user or we'll change this and say that a group can also own things which is the common case in real world scenarios? If we go for the later we would also need some concepts for delegation of management rights and transfer of ownership. Ins such cases we would also need something like "thing history" in which it will be tracked what has happened with the thing over a period of time.

@chombium I think we should aim for later, because we are targeting enterprise context here.
@nmarcetic @anovakovic01 we'll need a spec that describes all of this in a form of MIP (Mainflux Improvement Proposal ;)).

@drasko, @nmarcetic, @anovakovic01 Tell me how can I help writing the MIP ;)

@chombium we plan opening a repo like this.
@nmarcetic will add the input and then you can take it from there.

@chombium Good question ^
What are we going to do about managing the thing and the CRUD operations on them I would leave as is, so the ONLY user can own and create a thing, but user can give read/write permissions to the group, so group A can read/write thing B (same as owner). Because being owner is nothing more than filed, a policy with read/write or * would give you the same "power", but we will keep simplicity.

@nmarcetic agreed. That's exactly what I had in mind as well.
One other thing a bit off topic, but related: I think it would be also nice to also add a "service book" or "life history" for the things. Usually the sensors and the devices are assigned to someone to use and then they are returned or reused for other purpose. It would be nice if we have a log what has happened with a device from it's acquisition to it's decommissioned.  I guess such things can easily be implemented by the users based on our Event Sourcing. The question is if we need to add few more events so that we fire proper events. I know we have things like thing.connect and thing.disconnect, but I guess we'll have to adjust them too or even add two new events like "thing add/remove from group"

Hi, all. Is the MIP about multi-tenancy already in progress? I would like to contribute.
My 2 cents about the topic: I think that access control and multi-tenancy are related but it is not the same problem. Access control can help only partially with multi-tenancy requirements:

data segregation constraint: each tenant should have an isolated data space (as in NATS 2.0 Accounts or [Vernemq mountpoints]). (https://docs.vernemq.com/configuration/listeners#mountpoints)). Every component where data is stored (no matter if transient or persistent) should control this.
Authentication: Access to tenant space requires proper credentials (JWT, for instance).
Administration: Each tenant (administrators) will be able to manage own users, things, access control rules, dashboard options, etc.
Scaling: Potentially each tenant could produce a different resources usage of the system, requiring rate limiting, quotas, exclusive deployment resources, etc.)
Audit: Many systems will probably want some audit over system usage. Again this must be provided per tenant.
Billing: Related to previous topics, billing may be affected by system resources usage.

Mainflux current architecture is in a good shape to provide multi-tenancy. The only component that I do not see how to extend is Redis Streams (other than dirty hacks such as event attributes or multi-database settings).

@anovakovic01 I think that MIP issue has to be officially opened.

For the reference, comparison Casbin vs OPA: https://github.com/ory/keto/issues/47#issuecomment-419764819
Also, I noticed that it can be done as a library: https://www.openpolicyagent.org/docs/latest/#5-try-opa-as-a-go-library

@mteodor how are we doing with this one? Can you please explain here what has been done in https://github.com/mainflux/mainflux/pull/1228 and what are the future plans.

@dusanb94 do not forget to close this one once group migration is done.

This issue has been resolved a long time ago.


check_indexes: write page to explain Autovacuum Settings Changed warning

Write content here: https://smartpostgres.com/problems/autovacuum-settings-specified

Written: https://smartpostgres.com/problems/autovacuum-settings-specified/


Alt Key And Mouse Selectively Highlight Text

This is a feature request:
Can we get support for using the mouse and the Alt key to selectively highlight text?  Love dbeaver, but this is one productivity item that is missing from it.
Thank you for all the hard work!

Do you mean column selection mode? IF so then this feature is already there.
You can toggle it with Alt+Shift+A.
I'll add it in the SQL editor main menu.

Yes I am talking about that!  Thank you!  I must of missed it when I was googleing around.

That's not surprising because this feature isn't documented in DBeaver wiki.
It is a standard Eclipse feature.
Hopefully it'll be more obvious with toggle action in the main menu.


fix(AV-975): Fix issue with mismatching limit on report results

Replaced with https://github.com/vrk-kpa/opendata/pull/1582


Improving error message in plugin state where the refcounting hasn't been successful

refcount get, incr and decr functions return err instead of 1 in state where refcounting hasn't been successful.
updating the callers of above functions to make use of this error

Fixes #1348

Will keep existing implemention and modify the Remove handler to call GetInitSuccess and return the message appropriately.


Example transfer

https://medium.com/@samhagin/check-your-balance-on-coinbase-using-python-5641ff769f91

Coinbase API made believe that transfer_money would work for any kind of crypto conversion however it is not the case (moreover the python module is deprecated). The only way making exchange is to buy + sell but this method implies to add +10% fee each transaction which is not acceptable.


PSX.EXE GameID - Jumping Flash! (SCPS-10007) and Arc the Lad (SCPS-10008)

While testing the PSX.EXE GameID feature of Tonyhax International v1.5.3, I found that both Jumping Flash! and Arc the Lad cause the following message to be displayed: "Unknown PSX.EXE ID, unique GameID unavailable."

Please try this build
tonyhax-international-v1.5.4b6.zip

Heres another I'd like you to try, thanks
tonyhax-international-v1.5.4b7.zip

One last test build
tonyhax-international-v1.5.4b8.zip

In my testing, I found that although the two games are now recognized, PSX.EXE GameID no longer switches to a game specific VMC on my MemCard PRO 2, although SYSTEM.CNF GameID still works. On v1.5.3, I was able to use game specific VMCs for King's Field and Ridge Racer.

In my testing, I found that although the two games are now recognized, PSX.EXE GameID no longer switches to a game specific VMC on my MemCard PRO 2, although SYSTEM.CNF GameID still works. On v1.5.3, I was able to use game specific VMCs for King's Field and Ridge Racer.

Is this with beta 8?

After uploading it, I now realize how blurry that picture is. If it's necessary, I'll take another picture after moving the PlayStation to a different TV

Please try this
tonyhax-international-v1.5.4b9.zip

I'm still not having any luck. When the "Sending cdrom:????_???.??;1 as GameID" message appears, the MemCard PRO 2 screen does show the "Loading..." message as it normally does when it receives the GameID.

After that, it just uses the default VMC.

After that, it just uses the default VMC.

Are you using the mcpro for FreePSXBoot?

Yes

Yes

But system.cnf games do send the game id correctly?

After testing two SYSTEM.CNF games, they do send the GameID correctly

After testing two SYSTEM.CNF games, they do send the GameID correctly

Thanks for the reports, I think this should work correctly now
tonyhax-international-v1.5.4b10.zip

All four PSX.EXE games I tested now correctly send GameID, and SYSTEM.CNF games continue to correctly send GameID.

All four PSX.EXE games I tested now correctly send GameID, and SYSTEM.CNF games continue to correctly send GameID.

Nice. I'll release v1.5.4 pretty soon.

Fixed in v1.5.4 :)


SQLSTATE[42S02]: Base table or view not found: 1146 Table 'accessibility.sessions' doesn't exist (SQ...

Illuminate\Database\QueryException
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'accessibility.sessions' doesn't exist (SQL: select * from sessions where id = b5Q9mo0p6lapmYKnhMRFJqdPLbRLTuM0pI5QcKnB limit 1/controller='RedirectController',action='__invoke',url='%2F',route='generated%3A%3AqIkx8NitfdCkCsFj'/;)
:dart: Illuminate\Database\Connection::runQueryCallback
:page_facing_up: /app/vendor/laravel/framework/src/Illuminate/Database/Connection.php
758  // lot more helpful to the developer instead of just the database's errors.
759  catch (Exception $e) {
760*     throw new QueryException(
761          $query, $this->prepareBindings($bindings), $e
762      );

Open in Flare

This may be related to running the migrations without first putting the app in maintenance mode (php artisan down).

Related to the above, I think it might be the automatic health check that is pinging the application and trying to add a session while we were manually running php artisan migrate:fresh --seeder ProductionSeeder. In the future we should either put the server into maintenance mode first, or not run this migration/seeder. This seeder only really needs to be run on staging when there is a change to the production seeders. On production it should only be run before the initial setup of the application before the first "production" release.

Hasn't re-occurred in a while. It might have been resolved by putting the site into maintenance before resetting the dev site.


Vennverse Grant Proposal

Thank you for your submission, but I think you submitted this to the wrong repository. The VeChain grants program is this way: https://github.com/vechain/grant-program

I am sorry for this I was applying for W3f/grant only but I think someone from our team committed and pushed the wrong file to the repository I will resubmit the application for the grant.


Update versions

Update versions of Docker images and update of card format used format explained here: https://hyperledger.github.io/composer/latest/tutorials/deploy-to-fabric-single-org

@lvndry thanks for the PR.
Can you add the env variable CORE_PEER_GOSSIP_USELEADERELECTION=true and CORE_PEER_GOSSIP_ORGLEADER=false to the peers?
Also, we had to merge the other PR first, so there are some merge conflicts. Can you please resolve them? It is just removing the -a on the kubectl commands.


!pip install gives a warning in collaboration

If I run the first code block in google colab, it returns a warning:

WARNING: Upgrading ipython, ipykernel, tornado, prompt-toolkit, pyzmq can
cause your runtime to repeatedly crash or behave in unexpected ways and is not
recommended. If your runtime won't connect or execute code, you can reset it
with "Disconnect and delete runtime" from the "Runtime" menu.

WARNING: The following packages were previously imported in this runtime:
[zmq]
You must restart the runtime in order to use newly installed versions.
I get stuck there. Can anyone help solving this issue?

Hi @simonshabo , sorry for the delay. We have updated the colab notebook to address this issue. Could you please give it another try and let us know if the problem persists?


Build with Gradle

TODO
examples

https://github.com/eclipse/buildship
https://github.com/bndtools/bndtools

https://github.com/eclipse/buildship -> https://github.com/eclipse/buildship/blob/master/docs/pluginbuild/Usage.md -> https://bugs.eclipse.org/bugs/show_bug.cgi?id=489134

Gradle build with Bndtools would require to convert to Bndtools project

But first you must convert the Eclipse PDE project to a bnd/bndtools project and then you can build with the gradle plugin. PDE is manifest first and bnd is not.

bndtools/bnd#1381

one more option is wuff, but it's author is not active on GitHub since summer 2015
https://github.com/akhikhl/wuff/wiki/Convert-existing-Eclipse-plugins-and-apps-to-Gradle
trying in https://github.com/paulvi/macbadge

Bug 469287 - Provide Gradle tooling to build Eclipse plug-ins based on eclipsebuild.UpdateSitePlugin is closed unresolved


Lockfiles update

Continuing from https://github.com/devcontainers/spec/pull/101.
Default Behavior
Stated goals in the proposal: Reproduceablity, security, cachability.
The security goal is to protect the community from malicious code being injected after the lockfile has been written. For this the lockfile needs to be enabled by default.
The lockfile will prevent new bugs and new malicious code from propagating, but it will also prevent bug fixes and security updates from propagating. We could expand "disallowed features" to also support "deprecated/disapproved feature versions".
Supporting dependsOn
Notes
NPM's package-lock.json and Yarn's yarn.lock are similar in their approaches. Both support having multiple versions of the same package (at runtime each version can run separately). Notable difference:

package-lock.json v2 lays out the node_modules folder structure in the lockfile including checksums.
package-lock.json v1 refers to dependencies with "requires" which resolves to a single version. If a different version is required an additional "dependencies" object is added alongside the package's "requires" property.
yarn.lock uses a list of references as the top-level keys, each package lists dependencies refering to these references. If a different version is required, an additional top-level entry is added.

Conclusion
The current proposal can be used for features with dependencies. One limitation is that if two feature references are resolved with the same feature version, there will be two entries in the lockfile referring to the same version. E.g.:
{
    "features": {
        "ghcr.io/devcontainers/features/node:1": {
            "resolved": "oci:ghcr.io/devcontainers/features/node:1.2.4",
            "version": "1.2.4",
            "integrity": "sha256:567d704b3f4d3eca3acee51ded7c460a8395436d135d53d1175fb565daff42b8"
        },
        "ghcr.io/devcontainers/features/node:1.2": {
            "resolved": "oci:ghcr.io/devcontainers/features/node:1.2.4",
            "version": "1.2.4",
            "integrity": "sha256:567d704b3f4d3eca3acee51ded7c460a8395436d135d53d1175fb565daff42b8"
        }
    }
}

The proposal could be updated to avoid the redundancy, but that is not strictly necessary because the lockfile is managed by the tooling.

It might make sense to copy the "dependsOn" references (without options) from the feature manifest to the lockfile. package-lock.json and yarn.lock both do this and it makes them easier to understand (if one has to).
package-lock.json v2:
        "node_modules/@azure/core-http/node_modules/tough-cookie": {
            "version": "4.0.0",
            "resolved": "https://registry.npmjs.org/tough-cookie/-/tough-cookie-4.0.0.tgz",
            "integrity": "sha512-tHdtEpQCMrc1YLrMaqXXcj6AxhYi/xgit6mZu1+EDWUn+qhUf8wMQoFIy9NXuq23zAwtcB0t/MjACGR18pcRbg==",
            "dependencies": {
                "psl": "^1.1.33",
                "punycode": "^2.1.1",
                "universalify": "^0.1.2"
            },
            "engines": {
                "node": ">=6"
            }
        },

yarn.lock:
<EMAIL_ADDRESS>  version "3.1.3"
  resolved "https://registry.yarnpkg.com/anymatch/-/anymatch-3.1.3.tgz#790c58b19ba1720a84205b57c618d5ad8524973e"
  integrity sha512-KMReFUr0B4t+D+OBkjR3KYqvocp2XaSzO55UcB6mgQMd3KbcE+mWTyvVV7D/zsdEbNnV6acZUutkiHQXvTr1Rw==
  dependencies:
    normalize-path "^3.0.0"
    picomatch "^2.0.4"

One note on the structure.  I think i'd prefer change to omit the oci: prefix from the resolved property, perhaps moving the sourceInformation "type" to another property?
That way the 'resolved' property is something that can actually be placed into a devcontainer.json.
ie
{
    "features": {
        "ghcr.io/devcontainers/features/node:1": {
            "resolved": "ghcr.io/devcontainers/features/node:1.2.4",
            "sourceType": "oci",
            "version": "1.2.4",
            "integrity": "sha256:567d704b3f4d3eca3acee51ded7c460a8395436d135d53d1175fb565daff42b8"
        },
        "ghcr.io/devcontainers/features/node:1.2": {
            "resolved": "ghcr.io/devcontainers/features/node:1.2.4",
            "sourceType": "oci",
            "version": "1.2.4",
            "integrity": "sha256:567d704b3f4d3eca3acee51ded7c460a8395436d135d53d1175fb565daff42b8"
        }
    }
}

I think the resolved property should point to the exact SHA rather that the major.minor.patch semver label. While the patch version should be immutable, nothing prevents it from being mutated. The lockfile should point to the exact SHA.
Instead of node:1 resolving to node:1.2.4 with a SHA of 567d7... in the example below, node:1 should directly resolve to SHA 567d7.... That way if node:1.2.4 gets republished in the future, the lockfile still points to the original one and is unaffected. We still have the version property for easy reference to see what the version of the feature is, but the main pointer in the lockfile should directly point to the immutable SHA.
Before:
{
    "features": {
        "ghcr.io/devcontainers/features/node:1": {
            "resolved": "ghcr.io/devcontainers/features/node:1.2.4",
            "sourceType": "oci",
            "version": "1.2.4",
            "integrity": "sha256:567d704b3f4d3eca3acee51ded7c460a8395436d135d53d1175fb565daff42b8"
        }
    }
}

After:
{
    "features": {
        "ghcr.io/devcontainers/features/node:1": {
            "resolved": "ghcr.io/devcontainers/features/node@sha256:567d704b3f4d3eca3acee51ded7c460a8395436d135d53d1175fb565daff42b8",
            "sourceType": "oci",
            "version": "1.2.4",
            "integrity": "sha256:567d704b3f4d3eca3acee51ded7c460a8395436d135d53d1175fb565daff42b8"
        }
    }
}

I was using an outdated example, sorry about that. We are already using the hash in "resolved" and there is no type prefix. We just use the same syntax we use in the devcontainer.json's "features" keys with the hash.
To add dependencies for a devcontainer.json, e.g.:
{
	"image": "mcr.microsoft.com/devcontainers/base:ubuntu",
	"features": {
		"ghcr.io/codspace/dependson/C": true
	}
}

We could just list them without options, but including any version information. E.g.:
{
  "features": {
    "ghcr.io/codspace/dependson/A": {
      "version": "2.0.1",
      "resolved": "ghcr.io/codspace/dependson/a@sha256:932027ef71da186210e6ceb3294c3459caaf6b548d2b547d5d26be3fc4b2264a",
      "integrity": "sha256:932027ef71da186210e6ceb3294c3459caaf6b548d2b547d5d26be3fc4b2264a",
      "dependsOn": [
        "ghcr.io/codspace/dependson/E"
      ]
    },
    "ghcr.io/codspace/dependson/C": {
      "version": "2.0.0",
      "resolved": "ghcr.io/codspace/dependson/c@sha256:db651708398b6d7af48f184c358728eaaf959606637133413cb4107b8454a868",
      "integrity": "sha256:db651708398b6d7af48f184c358728eaaf959606637133413cb4107b8454a868",
      "dependsOn": [
        "ghcr.io/codspace/dependson/A",
        "ghcr.io/codspace/dependson/E"
      ]
    },
    "ghcr.io/codspace/dependson/E": {
      "version": "2.0.0",
      "resolved": "ghcr.io/codspace/dependson/e@sha256:9f36f159c70f8bebff57f341904b030733adb17ef12a5d58d4b3d89b2a6c7d5a",
      "integrity": "sha256:9f36f159c70f8bebff57f341904b030733adb17ef12a5d58d4b3d89b2a6c7d5a"
    }
  }
}

Each entry in the lockfile's "dependsOn" arrays is also part of the keys in the top-level "features" object. This way the lockfile applies to all installed features including dependencies and it contains a short-form of the dependency graph (ignoring differences in options).

In this example, how would the lockfile pin a dependency at that is both (1) in the user's devcontainer.json and (2) a dependency of another Feature, and also a different version?
Say ghcr.io/codspace/dependson/a depends on ghcr.io/codspace/dependson/e:2 and the user's devcontainer.json requires ghcr.io/codspace/dependson/e:3. That isn't captured in the lockfile, and the dependency may float to a later version. That's probably not what the user intends if they enable lock files.
Given the following `devcontainer.json
{
	"image": "mcr.microsoft.com/devcontainers/base:ubuntu",
	"features": {
		"ghcr.io/codspace/dependson/c": {},
                "ghcr.io/codespace/dependson/e:3": {}
	}
}

That will result in the following dependency graph:
flowchart
3992d6[ghcr.io/codspace/dependson/c]
aaaaaa[ghcr.io/codspace/dependson/e:3]
3992d6[ghcr.io/codspace/dependson/c] --> cbd9ef[ghcr.io/codspace/dependson/a]
cbd9ef[ghcr.io/codspace/dependson/a] --> 58daac[ghcr.io/codspace/dependson/e:2]
3992d6[ghcr.io/codspace/dependson/c] --> 58daac[ghcr.io/codspace/dependson/e:2]

I think we need to take the output of the dependency algorithm and write an entry for each Feature (perhaps deduping the ones that only vary by options).

I think we need to take the output of the dependency algorithm and write an entry for each Feature (perhaps deduping the ones that only vary by options).

Agreed. The graph does not need to be captured, but the transitive set of all features that were installed (including multiple versions of the same feature if multiple were installed) need to be recorded in the lock file as a flat list. The proposed syntax in https://github.com/devcontainers/spec/issues/236#issuecomment-1599031153 doesn't work for this since you'd have a collision, but the syntax in https://github.com/devcontainers/spec/issues/236#issuecomment-1550509063 where the version is included in the key would work.

I think the OCI identifier and the tarball URL are both case-insensitive. Since the casing can vary between devcontainer.json and devcontainer-lock.json's dependsOn, I suggest we specify that the lockfile always uses the lowercased identifier as the key in the features map.

Yes I know
Pada tanggal Kam, 20 Jul 2023 22.38, Christof Marti <
@.***> menulis:

Closed #236 https://github.com/devcontainers/spec/issues/236 as
completed.
—
Reply to this email directly, view it on GitHub
https://github.com/devcontainers/spec/issues/236#event-9876177095, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AWMKQNRRJEO4V6WHGNIDV2DXRFGILANCNFSM6AAAAAAX3PJPDM
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Fix showing $ sign in pledge form + minor clean-up

Comment as @polar-sh on issues that receive a new pledge. This happens for all issues if the issue doesn't have the Polar badge embedded, both for organisations that have the Polar app installed and those who doesn't.
Live example: https://github.com/zegl-testar/YES/issues/1
Fixes #661
@birkjernstrom I'll leave this one to you now, please check/update the copy if needed.
Before going live, you'll also need to update the personal access token in production to one that has the repositories permissions. I don't have access, so I'm leaving that to you too.

Nice @zegl! Super clear and I got it from here. Just finished packing before heading back to Stockholm within 1h. Likely won't get this deployed before then (not sure that would be smart timing either hehe), but I got this from here and will ship it this weekend 💪🏼

Changed the scope of this PR to include all the fixes and clean-up, but remove the feature of automatically commenting on issues not on Polar (yet).
Based on a few conversations with maintainers + HN comments, I think it's best we start with white-glove treatment for the pledges that come in for non-Polar users. We should still automate this, but with:

Only comment on orgs/repos not on Polar. Leverage Polar communication with maintainer otherwise
Only comment once

For now, I can manage this white-glove and manually (do things that don't scale) to learn for the initial pledges on how to massage messaging. So waiting a bit with this for now to prioritize other things & removed it in a single commit we can re-integrate later once it's time. Adding an issue for it.
https://github.com/polarsource/polar/issues/862


Ui Updated

Related Issuse or bug

Info about Issue or bug

Fixes: #81
Describe the changes you've made
I did the changes on helpline numbers page
UI changes
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
On running the project on local host.
Describe if there is any unusual behaviour of your code(Write NA if there isn't)
A clear and concise description of it.
Checklist:

[ ] My code follows the style guidelines of this project.
[ ] I have performed a self-review of my own code.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
[ ] My changes generate no new warnings.
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] New and existing unit tests pass locally with my changes.
[ ] Any dependent changes have been merged and published in downstream modules.

Screenshots

Original
Updated

original screenshot
up

dated screenshot

Resolve the conflicts and make some changes that I have stated in the issue.

Issue resolved.


fatal error: unexpectedly found nil while unwrapping an Optional value

The line 196 return String(data: dec, encoding: String.Encoding.utf8)!  is nil but using ! to return the wrapped value causing crash.
fileprivate class func aesDecrypt(_ str: String, key: String, iv: String) throws -> String {
    let keyData = key.data(using: String.Encoding.utf8)!
    let ivData = iv.data(using: String.Encoding.utf8)!
    //let data = Data(base64Encoded: str, options: NSData.Base64DecodingOptions(rawValue: 0))!
    let data = Data(base64Encoded: str)!
    let dec = try Data(bytes: AESCipher(key: keyData.bytes,
                                        iv: ivData.bytes).decrypt(bytes: data.bytes))
    return String(data: dec, encoding: String.Encoding.utf8)!
}

We should always avoid using ! to access the wrapped value for optional types.

you are absolutely right! I am actually just now packaging a new version which includes the following fix https://github.com/SwiftyBeaver/AES256CBC/pull/11

fixed by today’s 1.2.0 release 🎉

Very well done @skreutzberger and very quick reply and fix! And you are doing a great job of this project.

Thanks!


System stuck in EFI shell after setup.sh (main, games)

The system boots straight into EFI shell after a restart.

I don't know if anyone actually usews this repo besides me, but I'll pin relevant issues for now and add a note to the READMEs if this doesn't get fixed soon.

Also see #138


Unable to generate token from secret, throws a 403 forbidden error

Hi there,
I am trying to connect my React webchat client to my local bot and as per this tutorial, I made a GET request in this format:
requestGET https://webchat.botframework.com/api/tokens
Authorization: BotConnector YOUR_SECRET_HERE

It doesn't process my request and throws a 403 forbidden error. The secret I am supplying is from WebChat channel. I also tried DirectLine channel secret (even added my localhost in the trusted origins) but it's the same story.
The bot works fine in the emulator though and I am able to get a token when I make a request from postman.
Any help would really be appreciated.
Thank you

@naser-baig-au4,
The api/tokens endpoint is a Direct Line API 1.1 protocol which returns a string.
As such, I believe you are errantly passing in the string version of the token, including the surrounding quotes. Use JSON.parse() on the token to get a correctly formatted token. Doing so should allow you to pass in and successfully create the Direct Line object and, thus, connect Web Chat to your bot.
That being said, the recommended protocol to use is Direct Line API 3.0 which will return the token as a JSON value (i.e. containing no surrounding quotes).
I'm closing this as resolved. If the issue persists, please feel free to re-open.

As such, I believe you are errantly passing in the string version of the token, including the surrounding quotes. Use JSON.parse() on the token to get a correctly formatted token.

Hi @stevkan,
Thank you for the reply. I don't have any issues parsing the token. I am unable to fetch the resource for the token as I am greeted with a 403 forbidden error.

That being said, the recommended protocol to use is Direct Line API 3.0 which will return the token as a JSON value (i.e. containing no surrounding quotes).

Also tried with the 3.0 protocol and it's the same story.
Perhaps this screenshot might help:

Could somebody please open this issue again?

@naser-baig-au4, can you verify the actual value of the token being passed in either by console logging, setting break points, or some other? My concern is that, while the steps you are performing are correct the value, itself, may still be formatted wrong.

@naser-baig-au4, can you verify the actual value of the token being passed in either by console logging, setting break points, or some other? My concern is that, while the steps you are performing are correct the value, itself, may still be formatted wrong.

@stevkan, please check the screenshot above. I am unable to generate the token in the first place, let alone properly pass it to webchat via directline.

@naser-baig-au4, apologies. You stated you "don't have any issues parsing the token". I took that to mean you were actually receiving one. I'll take another peak at the process and get back to you.

@naser-baig-au4, apologies. You stated you "don't have any issues parsing the token". I took that to mean you were actually receiving one. I'll take another peak at the process and get back to you.

No worries. Please take your time :)

@naser-baig-au4, I'm still not encountering the same issue you are. Could you post you web chat code (hiding any secrets or keys) so I can attempt a repro?

@naser-baig-au4, I'm still not encountering the same issue you are. Could you post you web chat code (hiding any secrets or keys) so I can attempt a repro?

Hey @stevkan,
I have used this sample as a starting point and just made the change in the URL to the directline URL mentioned above. Everything else is the same.
I have an update for you. I was able to connect to my bot locally using offline directline. Is it possible that I am getting this error because I have just deployed my bot and not published it yet?

@naser-baig-au4, thank you for your patience.

I have an update for you. I was able to connect to my bot locally using offline directline. Is it possible that I am getting this error because I have just deployed my bot and not published it yet?

No, you can run a bot locally and connect to outside services as long as you use a service like ngrok and also have a bot registration created on Azure. Ngrok, and other similar options, provide a tunnel between your local host machine and your bot registration / service running on Azure.
Do you have a bot registered on Azure, as described in the steps shown in this doc?
Also, did you ever try the Direct Line API 3.0 set up, referenced previously?

Closing due to a lack of activity. If the issue persists or you have new information to provide, please feel free to reopen.


Dark theme implementation for Sway Playground

Closes #45
Videos may be a bit laggy as my PC is not quite powerful:)
Intro
Hey there, I've done a Dark Theme for Sway Playground by creating themeContext and then just made other components to know about the current state of theme.A bit below I'll explain all my steps in details, just wanted to say that I really want to have this working so I'm open for making changes and enhancing the implementation of the dark theme.

P.s. As you can see on the videos, in the PC version you have a button to switch between themes + on page load the theme automatically applies depending on your system preferences. On the Phone version, there is no switch button, but it renders the theme that is the same as your system preferences.

Implementation explanation
I think I'll start with explaining how I set up a theme and then I'll go through the components I've edited.

themeContext.ts

Using React context API I created a context.It has a theme property (it has 2 states - light or dark), and setTheme - to set a theme (on page load or on SwitchThemeButton click).
Also created useThemeContext hook so we can make sure theme has been set up properly and with it we will be accessing theme and setTheme.

SwitchThemeButton.tsx

The main functionality just a simple switch theme button, that sets the theme to an opposite one once clicked.
Other code is styling (sets a Moon Icon when the dark theme is set and a Sun Icon when the light theme is set).

App.tsx

For some reason on github, it shows my changes kinda wrong.
The changes you see below is everything I've done in App.tsx:
import {Theme,ThemeContext} from './theme/themeContext'  //imported Theme and custom hook
const [theme,setTheme]=useState<Theme>('light'); // Current theme state

And wrapped my entire app with Theme Provider so all my components are aware of the current theme state:
return (
    <ThemeContext.Provider value={{setTheme,theme}}>
            //all the code in return
    </ThemeContext.Provider>
  );

Finally, depending on theme set the background color of our main div:
background: theme==='light' ? '#F1F1F1': 'black',

Copyable.tsx

Imported custom useThemeContext hook with which accessed current theme state:
const theme = useThemeContext().theme;

These steps will be repeated in many places, so instead of just writing these lines, again and again, keep in mind that step as Step 0

Depending on the theme, apply color to the div and ContentCopyIcon.

SecondaryButton.tsx

Depending on the theme, apply color and bg color to the Button.

shared.tsx

Created a BorderColor function which depending on a theme will change StyledBorder color.

DarkThemeStyling - this is styling for dropdowns and inputs for dark theme,

ExampleDropdown.tsx & ToolchainDropdown.tsx

Imported DarkThemeStyling

Created a dropdownStyling which depending on the theme state will use styling from shared.tsx or will return nothing (default styling will be applied). And this styling we will pass to sx of FormControl.

Added MenuProps and removed background styling from Select components for styling purposes.

LogView.tsx

Depending on the theme, change the color of LogView.

SolidityEditor.tsx & SwayEditor.tsx & ComplexParameterInput.tsx

Imported another editor theme from AceEditor - tomorrow_night_bright

With useMemo depending on the theme's current state set themeStyle to tomorrow_night_bright  |  chrome

In the AceEditor component assign the theme: theme={themeStyle}

DryrunSwitch.tsx

Depending on the theme, change the color of Switch and text close to it.

FunctionCallAccordion.tsx

Depending on the theme, change the style of Accordion, ExpandMoreIcon, and FormLabel.

FunctionParameters.tsx

I decided to create a custom TableCellComponent to avoid passing the same changes over and over again.

Replaced TableCellComponent instead of TableCell, but in the place of parameters input left TableCell to be able to input our parameters.

FunctionToolbar.tsx

Depending on the theme, change the color of the title.

InteractionDrawer.tsx

Depending on the theme, change the color of the background and text.

ParameterInput.tsx

For that I used the same approach as for ExampleDropdown.tsx & ToolchainDropdown.tsx

ResponceCard.tsx

As usual - just color and background styling depending on the current theme state.

background: theme === '' ? 'white' : 'transparent'
This line removed just a small white outline when dark theme is set.`

ActionTollbar.tsx

1.Using useEffect hook on page load we check the system preferences of the user and set the theme state to user preferences.

As I didn't pass dependencies when useEffect should be called: it will be called only once - on page load.

{!isMobile && <SwitchThemeButton />} - check if we are not in the mobile version then we should be able to see SwitchThemeButton.

That is pretty much it.If something needs to be refactored or changed, will be glad to make edits <3
https://github.com/FuelLabs/sway-playground/assets/78500984/8498e600-56f5-43e2-9127-89583e371b06
https://github.com/FuelLabs/sway-playground/assets/78500984/0fa425dd-7a02-4dca-8446-f8b2e8da8385

I noticed also that the theme button disappears when the "interact" drawer is open.

 I've made the changes you've commented!

Thank you for the contribution! This is looking really good. I have a few initial comments and I will dig in deeper on Monday.
In Dark Mode, I think all buttons other than compile should have a light gray color for the text rather than green. This highlights the compile button, which is the primary button on the page. It might look better for the compile button to have green text with a dark backrgound. I will experiment with it and test it out soon.
Thank you again!

 I've made some changes you've commented on and waiting for your reply regarding dark theme buttons styling.

I like the look in the latest video you posted best (OnHoverGreen.mp4). A couple more comments on the style:

Could we make the text of the disabled action button text a bit lighter? Darker than the enabled buttons, but light enough so that it's still easily readable.

Could we match the style of the editor dropdown to light mode? That is, outlined in light grey rather than a green shadow. Like this (But with the arrows grey instead of green):

When hovering over a secondary action button, could we make the background change color to dark green rather than the text color changing? That would mirror what happens in light mode. I think it's better for consistency with other buttons in the app for the background color to change on hover rather than the text color.

Something like this (using the colors from @fuel-ui/css):

I like the look in the latest video you posted best (OnHoverGreen.mp4). A couple more comments on the style:

Could we make the text of the disabled action button text a bit lighter? Darker than the enabled buttons, but light enough so that it's still easily readable.

Could we match the style of the editor dropdown to light mode? That is, outlined in light grey rather than a green shadow. Like this (But with the arrows grey instead of green):

When hovering over a secondary action button, could we make the background change color to dark green rather than the text color changing? That would mirror what happens in light mode. I think it's better for consistency with other buttons in the app for the background color to change on hover rather than the text color.

Something like this (using the colors from @fuel-ui/css):

General note: We should use green sparingly, only where it's used in the current light mode. Where light mode has black, dark mode should have light. Where light mode has dark grey, dark mode should have light grey, etc. The fuel color scheme is mostly black and white with only a few hints of green where emphasis is desired. I believe the only green in the whole app is in the action toolbar buttons & spinner. Not at all in the "Interact" drawer.

Thank you for all the comments/suggestions I've readthem all,will make changes during weekends and come back with an updated version!

Good day! I think I've made all the changes you mentioned, tried to stick to black/white styling that time but if some colors need to be changed - I'll change them.

This is looking really good! I'll do another review of the code tomorrow. A couple things I noticed from the preview:
It's a bit hard to tell this is a toggle

The disabled compile button should be a darkened green

Needs a bit more contrast on the log timestamps to be easily readable

Thank you for an update, woking on the changes 🫡

Good day, I hope I didn't miss anything. Now it is looking way better than in my first commit)) I've been thinking: Would it be a good idea to move styled custom components to shared.tsx or they are good to go?Is there anything else I should change?

Regarding dividers in dark mode, I could create a custom StyledDivider in useLog.tsx but with that approach, styling doesn't change even if the theme is changed.So I created StyledDivider in shared.tsx, and it works fine on theme change.What do you think about this approach, should I leave it like that or find another way?

Also how about this copy Icon green - I remember you said that green should be used just for the loader and compiler button.Just my suggerstion that it looks better with green there.

Sorry, I had a couple more comments from Friday that I forgot to post. I will go ahead and commit them if I can and then approve. Thanks for your hard work on this PR!

Thank you so much, it was a please for me!


feat(replica reconciler): missing replica owners

Include a reconcile loop which removes any replica owners which no
longer exist.
Resolves: CAS-1203

bors merge

bors merge


Support multiple checkboxes

This tutorial only shows support on a single textbox (http://learn.ractivejs.org/#!/two-way-binding/2)
How do you get/set values for multiple textboxes?
{{#FormData.Lookup.Targets}}
      <label class="checkbox"><input type="checkbox" name="target" value="{{Id}}"/>{{Name}}</label>
{{/FormData.Lookup.Targets}}

Hi! Today that problem have again.
ractive-bootstrap.js we have .....<input name="{{name}}" type="radio" .......
and when I try use tag 'name' of input I have in HTML - <input name="{{name}}" type="radio"
Why? What can I do?
If I change template to this .... <input name_="{{name}}" type="radio" ....
as result I have in DOM - <input name_="foo" type="radio"
Please, halp me!

If you're trying to get the name attribute to show up in the actual DOM, you should be able to to add a twoway directive to the input e.g. <input type="radio" name="{{name}}" twoway="false" ... />. Ractive uses the name attribute with a single mustache as flag to set up a two-way binding by default. You could also disable two-way for the whole instance by passing twoway: false as on option when Ractive gets initialized.

ohh YES! Thank you very much!!!
ср, 16 мар. 2016 г. в 4:27, Chris Reeves<EMAIL_ADDRESS>
If you're trying to get the name attribute to show up in the actual DOM,
you should be able to to add a twoway directive to the input e.g. <input
type="radio" name="{{name}}" twoway="false" ... />. Ractive uses the name
attribute with a single mustache as flag to set up a two-way binding by
default. You could also disable two-way for the whole instance by passing twoway:
false as on option when Ractive gets initialized.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/ractivejs/ractive/issues/103#issuecomment-197117527


Release 1.9.0

We have already camel-k-runtime 1.13.0 and camel-kamelets 0.8.0 staged.
I'd like to release 1.9.0. Is there something that needs to be merged before?
@squakez @astefanutti

+1, thanks @oscerd!

I'd like to try to merge this before releasing #3198 . Let me see if I manage to solve the test failures within a couple of hours, otherwise we can release without that.

I also have a tiny change in the making that I use to grab metrics on the build queue duration per integration during my performance testing. I will also try to get this done before noon if you do not mind.

There are hard failures in #3198 I will need more time to fix. We can proceed releasing 1.9 without this feature.

Same here. I need more time to make it a mature change. Please move on with the release without my changes

We probably need to release runtime again

If we all agree to release, I'm going ahead between today and tomorrow.


Random pix key

We missed the random type key in our implementation.
I actually started the conversation in the wrong repo :stuck_out_tongue:
https://github.com/Phillarmonic/cpf-cnpj/issues/5
We have a regex for that.
https://developers.international.pagseguro.com/reference/pix-key-validation-and-regex
Very similar to a uuid.

Adding to my queue in the project at https://taskavel.com/

Also, again, thank you for bringing this to my attention.
Z.

From your experience, performance-wise, which one is better?

A custom validation logic
preg_match()

I think using regex is usually faster. For simple regular expressions that might not cause regressions and need a different regex engine like the RE2 of Golang like when the Cloudflare regex issue that took them down due to infinite regression, then using regex is advisable.
It all comes down to how predictable the expression is. In the case of CPF and CNPJ, we need to do extra calculations to make sure a number is valid.
In the case of a random key, all we need to do is check if the format matches, because there's no inherent validation check logic to the data.
I have also written a framework in PHP from scratch to study how routers, dependency injection and other aspects work. By far the fastest and more performant approach for route resolution (that is quite more complex than this) was to match things with regex. And then implement logic from there. I got very happy when I made dependency injection work from scratch :stuck_out_tongue: I felt very proud.
So, yes. Considering the nature of the data, regex will do.

Linear time regex engines are very interesting.
"Let this be a warning to all who are performing extremely convoluted regex matching at scale".
Wise words. And you cannot go bigger than Cloudflare.
Very well. We're not cloudflaring our way through the problem, so I'd say using regex is pretty safe, quick and efficient (dirty?)
Updated task at Taskavel. Give me some time to cook this up.

I have also written a framework in PHP from scratch

Also, can you share this with me? I wanna see how you implemented Dependency Injection.
Z.

PHP 8.4 was just released. We're now at 8.4.1. Tests passed :)


Keep Toolbar when the panel is EXPANDED

Hi,
i need to keep the toolbar in my view, so is there a way that i can keep the toolbar and let the sliding panel pass under the toolbar  ?

yes. set parallax offset to zero.