django-otp 0.8.0 seems to break django-two-factor-auth

I had to downgrade to an older version of otp (django-otp==0.7.5) to run my migrations. In the setup it says: "'django_otp>=0.6.0,<0.99", which I don't think hold anymore. I don't know on which end the error is. This is the error message with django-otp==0.8.1 (and 0.8.0):
File "/opt/.pycharm_helpers/pycharm/django_manage.py", line 52, in
run_command()
File "/opt/.pycharm_helpers/pycharm/django_manage.py", line 46, in run_command
run_module(manage_file, None, 'main', True)
File "/usr/local/lib/python3.6/runpy.py", line 205, in run_module
return _run_module_code(code, init_globals, run_name, mod_spec)
File "/usr/local/lib/python3.6/runpy.py", line 96, in _run_module_code
mod_name, mod_spec, pkg_name, script_name)
File "/usr/local/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/opt/project/manage.py", line 21, in
execute_from_command_line(sys.argv)
File "/usr/local/lib/python3.6/site-packages/django/core/management/init.py", line 371, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python3.6/site-packages/django/core/management/init.py", line 365, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python3.6/site-packages/django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python3.6/site-packages/django/core/management/base.py", line 335, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python3.6/site-packages/django/core/management/commands/migrate.py", line 200, in handle
fake_initial=fake_initial,
File "/usr/local/lib/python3.6/site-packages/django/db/migrations/executor.py", line 117, in migrate
state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
File "/usr/local/lib/python3.6/site-packages/django/db/migrations/executor.py", line 147, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "/usr/local/lib/python3.6/site-packages/django/db/migrations/executor.py", line 244, in apply_migration
state = migration.apply(state, schema_editor)
File "/usr/local/lib/python3.6/site-packages/django/db/migrations/migration.py", line 122, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/usr/local/lib/python3.6/site-packages/django/db/migrations/operations/fields.py", line 216, in database_forwards
schema_editor.alter_field(from_model, from_field, to_field)
File "/usr/local/lib/python3.6/site-packages/psqlextra/backend/base.py", line 127, in alter_field
model, old_field, new_field, strict
File "/usr/local/lib/python3.6/site-packages/django/db/backends/base/schema.py", line 525, in alter_field
old_db_params, new_db_params, strict)
File "/usr/local/lib/python3.6/site-packages/django/db/backends/postgresql/schema.py", line 122, in _alter_field
new_db_params, strict,
File "/usr/local/lib/python3.6/site-packages/django/db/backends/base/schema.py", line 630, in _alter_field
new_default = self.effective_default(new_field)
File "/usr/local/lib/python3.6/site-packages/django/db/backends/base/schema.py", line 218, in effective_default
default = field.get_default()
File "/usr/local/lib/python3.6/site-packages/django/db/models/fields/init.py", line 775, in get_default
return self._get_default()
File "/usr/local/lib/python3.6/site-packages/two_factor/models.py", line 59, in random_hex_str
return random_hex().decode('utf-8')
AttributeError: 'str' object has no attribute 'decode'

Same here…

That's True, django-otp 0.8.0 is not compatible with latest django-two-factor-auth. Commit 0fc4a54 which fixes this issue is in master, but not released yet. Meanwhile, you should depend on django-otp 0.7.5.

I'll see if I can get a release out this evening :+1:

"get a release out this evening" turned into "Python 3.4 builds are breaking and I'm too tired to understand why" (Python 3.4 actually EOL'd nearly a year ago is why)

Drop anything < 3.7.

@Natureshadow why? 3.6 will still be supported into 2021 and as far as I know there's no special compatibility code in this package for 3.5 and 3.6

Well, keep it if you want, but I will be around to remind you when it causes issues because it was kept until 2025 ;).

Running into this as well, switching to django-otp 0.7.5 in the mean time

Thanks for the quick fix. Is there anything blocking a release now?

No, I just need to get around to doing it!

It would be helpful to have this fix :)


Accuracy of second derivatives, specifically for tabular lookups

@aematts brought up the fact that certain thermodynamic derivatives may be more accurate than others, especially for tabular lookups.
We currently provide three second derivative quantities--the Gruneisen parameter, $\Gamma$, the constant volume heat capacity, $C_V$, and isentropic bulk modulus, $B_S$--that can then in principal be used with our other return variables to compute any desired thermodynamic quantity of interest. However, these are not always the most accurate quantities for a material, especially depending on the preferred inputs for that EOS.
More specifically, for Mie-Gruneisen EOS of the form $P = P(\rho, e)$, the natural derivatives to be returned are
\left( \frac{\partial P}{\partial e}\right)_\rho = \rho \Gamma

and
\left( \frac{\partial P}{\partial \rho}\right)_e = \frac{B_S - P\Gamma}{\rho},

which is what motivates returning the Gruneisen parameter and isentropic sound speed in the first place (check my math though).
However, for an EOS of the form $P = P(\rho, T)$, the natural derivatives are better expressed in terms of $\alpha := -\frac{1}{\rho}\left(\frac{\partial \rho}{\partial T}\right)_P$ and $B_T := \rho\left(\frac{\partial P}{\partial \rho}\right)_T$ such that the natural derivatives are
\left(\frac{\partial P}{\partial T} \right)_\rho = \alpha B_T

and
\left(\frac{\partial P}{\partial \rho} \right)_T = \frac{B_T}{\rho}

This could be especially relevant for FillEos() or an eventual sound speed function as identified in https://github.com/lanl/singularity-eos/issues/4.
For an analytic EOS, this probably won't matter much since any differences in the calculation will be of order roundoff, but interpolation errors in the derivatives in density-energy space will likely be larger than in density-temperature space. It may then be advantageous to minimize these interpolation errors and formulate returned quantities in terms of $\alpha$ and $B_T$.
Moreover, it may make sense to expose routines to access these quantities directly at some point in the future if the interpolation errors can be proven to be significant enough.

Correct me if I'm wrong, but I believe we are doing this in certain places. For the tabulated EOS's I think we try to compute things in terms of the derivatives with respect to the independent variables then use thermodynamic relations to get the derivatives relevant for a hydro code.

Correct me if I'm wrong, but I believe we are doing this in certain places. For the tabulated EOS's I think we try to compute things in terms of the derivatives with respect to the independent variables then use thermodynamic relations to get the derivatives relevant for a hydro code.

Yes I believe you're right, but it might be appropriate to standardize some of this across EOS. I think the other question is whether to expose routines for accessing the thermal expansion and isothermal bulk modulus. I don't see a need at the moment, but it may be important in the future as the library is integrated into more physics (like KPT).


Define main code

Avoid mixing code with classes and separate it explicitly using the

if name == "main"

Also, please leave a proper header in each file with authorship information and a brief description. I left an example in this file.
The same applies for the class code! Please document it properly and target a documentation software, such as, readthedocs.


USDT approval flow

USDT requires users to have zero approval before changing it to another value.  We should consider this in all approval flows with the token to properly handle this. It will require 2 transactions for a user who needs approve a higher amount.
For example Approval amount needed is 100:

current approval amount it 10,
user first needs to approve 0 and then approve 100 for usdt to allow for the change.

AC

Add messaging to alert user to issues with USDT approval flows
this is handled in all approval flows where USDT could be used (swaps, TC defi products, other defi products, etc)

related https://github.com/shapeshift/web/issues/7059

Figma reference here:
https://www.figma.com/design/ZkRqq0Bk1glXqIW776IAtr/Portals?node-id=538-5320&t=zgFb47wWZnHZ5pVr-0

Confirmed reset functionality is not necessary for THORChain lending.
I was able to approve spend of 790 USDT: https://snowtrace.io/tx/0x51d69ce85c99c0aa9399542140c13016e61a608524653255805e81f2906a1ecf?chainid=43114
And then 793 USDT: https://snowtrace.io/tx/0xfac1bf3846a4ac6a34568afdfa86bb0c557b1047f93e1e0f947fcc9fe0d49087?chainid=43114
All via the ShapeShift UI, allowing the user to then interact with the THORChain contract and successfully repay a loan:  https://snowtrace.io/tx/0xaa10385bf7b82e47ff20717e3123b9ace25fec426ea49d2850f00b71ecc924f0?chainid=43114 & https://viewblock.io/thorchain/tx/aa10385bf7b82e47ff20717e3123b9ace25fec426ea49d2850f00b71ecc924f0

Likewise, confirmed not necessary for THORChain LP deposits:
First approval: https://snowtrace.io/tx/0x017cbb04804ab3a16cba68c0edde0ce9d3ba27f21632d1e8b29c5a7c7251f953?chainid=43114
Second, higher approval without reset: https://snowtrace.io/tx/0x7de6767eff42c726012b4ca5a663dfa37f0529e93ff754f50263418876c903e8?chainid=43114
Successful LP deposit: https://snowtrace.io/tx/0x894218bbcf918d0e8e72d2bc230f3fca65dcf129e335b6949cfbb10e2506bee6?chainid=43114 & https://viewblock.io/thorchain/tx/894218bbcf918d0e8e72d2bc230f3fca65dcf129e335b6949cfbb10e2506bee6


⚠ Node - us-2d538c95.yalaso.top has degraded performance

In d261a5e, Node - us-2d538c95.yalaso.top (http://us-2d538c95.yalaso.top/api/v1/ping) experienced degraded performance:

HTTP code: 200
Response time: 2505 ms

Resolved: Node - us-2d538c95.yalaso.top performance has improved in 3ecfe20 after 11 minutes.


fix column pruning do not do well

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Updated PHPUnit and dropped PHP 5.5 support

@webimpress

Looks fine, but I think we should update year in license header in changed files (year 2017(.

Good catch!

Thanks, @froschdesign


Added cheap sunglasses into ClothesMate

About the PR

Added cheap sunglasses that wasnt protect against flashing into ClothesMate
Why / Balance

To replace removed regular sunglasses in ClothesMate https://github.com/space-wizards/space-station-14/pull/25221
Technical details

n/a
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

add: Added cheap sunglasses that wasnt protect against flashing into ClothesMate

Make them identical to regular sunglasses and just add "look cheap" to the description :trollface:

Make them identical to regular sunglasses and just add "look cheap" to the description :trollface:

i agree

Wasn't sunglasses removed from the clothesmate not that long ago?

The test is failing because i THINK the sunglasses increased the total overall price of the clothesmate restock box selling price (probably from the parent?). Might be good to double check this because the branch might just be out of date or there is another reason why it is higher.


(node) warning: possible EventEmitter memory leak detected. 11 listeners added

We tried switching from Q to bluebird in the Jest project, and started constantly to get this warning:
(node) warning: possible EventEmitter memory leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
  at process.addListener (events.js:160:15)
  at process.on.process.addListener (node.js:802:26)
  at /Users/dmitrys/jest/node_modules/bluebird/js/main/async.js:80:25
  ....

We ran many tests in parallel, seems many promises are created, but Q didn't have this issue.

We can probably fix it in our code by setMaxListeners(n):
process.setMaxListeners(0);

Although, probably bluebird may want to do the same in here.

I'd argue this isn't something that bluebird should do, as it has global side-effects, and because it can already be fixed on the application's (or in this case, jest's) side. Plus, it might cover up real leaks, though 10 seems like a pretty arbitrarily low value. We probably only get the error in jest because of the software's complexity.

Bluebird is just adding 1 handler here (per instance) if I understand
correctly so it's really not up to bluebird to put that limit at a very
high number because as the previous comment said it might cover up a real
issue.
On Tue, Jun 23, 2015 at 8:17 PM, Benjamin Woodruff<EMAIL_ADDRESS>
wrote:

I'd argue this isn't something that bluebird should do, as it has global
side-effects, and because it can already be fixed on the application's (or
in this case, jest's) side. Plus, it might cover up real leaks, though 10
seems like a pretty arbitrarily low value. We probably only get the error
in jest because of the software's complexity.
—
Reply to this email directly or view it on GitHub
https://github.com/petkaantonov/bluebird/issues/661#issuecomment-114576563
.

Well, Bluebird could do
if (process._maxListeners)
    process.setMaxListeners(process._maxListeners + 1);

if there is really a need for this.


Useless error description when using near-operation-file and unions

Describe the bug
When using the @graphql-codegen/near-operation-file-preset to generate type definitions via the typescript plugin, the error messages when the query is invalid misses all relevent information to actually fix the problem.
Instead there are two different types of errors thrown:
when querying for fields that do not exist on all types of the union
TypeError: Cannot read properties of undefined (reading 'type')
        at node_modules/@graphql-codegen/visitor-plugin-common/index.js:3038:65

when querying for an object that does not exist
lastType.getFields is not a function
    Error: Unable to validate GraphQL document!
        at node_modules/@graphql-codegen/near-operation-file-preset/index.js:206:19

To Reproduce
Steps to reproduce the behavior:
https://codesandbox.io/s/graphql-codegen-near-operation-file-error-5n915?file=/document.graphql

My GraphQL schema:

type A {
  id: Int!
}

type B {
  id: Int!
  fieldOnlyOnB: String
}

union AorB = B | A

type Query {
  getAList: [A!]!
  getBList: [B!]!
  getABList: [AorB!]!
}

schema {
  query: Query
}

My GraphQL operations:

query {
  getABList {
    id
    # this works as expected, since it is perfectly valid
    ... on B {
      fieldOnlyOnB
    }

    # throws "Cannot read properties of undefined (reading 'type')"
    fieldOnlyOnB

    # throws "lastType.getFields is not a function"
    invalidField { invalidSubField }
  }
}

My codegen.yml config file:

schema: schema.graphql
documents: document.graphql
generates:
  types.ts:
    # comment out the nexxt line and you will see proper error messages
    preset: near-operation-file
    presetConfig:
      extension: .types.ts
      baseTypesPath: "types.ts"
    plugins:
      - typescript

Expected behavior
Proper, useful error mesages about errors in my query. The same as if I was not using the near-operation-file preset.
In the sandbox, just comment out the line preset: near-operation-file in codegen.yml and you will see the error messages that I expected.
Environment:

OS: MacOS 12.2
@graphql-codegen/add: ^3.1.1
@graphql-codegen/cli: ^2.4.0
@graphql-codegen/near-operation-file-preset: 2.2.4
@graphql-codegen/typescript: 2.4.3
@graphql-codegen/typescript-operations: 2.2.4
graphql: ^16.2.0
NodeJS: v16.10.0

Additional context
Obviously this is a very simplifyed reproduction case. Originally the problem occurred when we made a few changes to our API to use union types in certain situations.
When trying to run codegen afterwards, not having proper error messages made it very hard to update the client queries…

To be honest, I think this is a flat out bug – not an enhancement.
You can very easily run into scenarios where you run codegen and not even get an error for what should be an error. The above largely describes "useless" errors, but I didn't any any errors at all. Also as described above, this can easily be reproduced by removing preset: near-operation-file, and the errors will kick in.

This does not only happens on union cases, and it's pretty annoying not know whats the actual error and just get "Unable to validate GraphQL document"

Any updates on how to get around this? I'm currently stuck on this issue

I've moved this issue to https://github.com/dotansimha/graphql-code-generator-community/issues/934 because @graphql-codegen/near-operation-file-preset lives there.


chore: Release-pipeline Add manual trigger & latest version

Could you elaborate more what "Add manual trigger & latest version" means? Does the introduced, newer versions do something extra out of the box?

Could you elaborate more what "Add manual trigger & latest version" means? Does the introduced, newer versions do something extra out of the box?

Manual trigger/button:

There was a security warning on version 1. So updated to latest


How to use code ways to get an abnormal camera back to work?

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
D435

Firmware Version
<IP_ADDRESS>

Operating System & Version
Win10

Kernel Version (Linux Only)
(e.g. 4.14.13)

Platform
PC

SDK Version
2.25.0

Language
python3.6

Segment
Robot

Issue Description
I use six cameras on a computer for target recognition, but occasionally, the camera connection is abnormal. I have tried many methods, such as hardware_reset() in pyrealsense, or use devcon tool to disable or enable or restart the USB device, but nothing help, the only solution is to unplug the USB cable and plug it in again, but doing so is not realistic for our device. I think if you guys can tell me a way to disconnect the power of USB by code ways(because I think it's probably equivalent to replugging), if so, please let me know.
Best regard!
Dontla

If hardware_reset() does not work for you then you could try resetting the USB port with a script such as the one in the link below.
https://github.com/ralight/usb-reset/blob/master/usb-reset.c

Please let us know if further assistance is needed. Thank you.


Question: Next release?

Sorry for placing a question as an issue..
when do you intend to release a new version to nuget? I can't use the one published, I get reference issues in my .net core 2.0 application, but when referencing the master branch with the latest changes then its fine.

Having a chat today with @tugberkugurlu in regard to this.. no promises, but please stay tuned.


New package: BandLab.Cakewalk version <IP_ADDRESS>

Pull request has been created with komac v2.2.1 :rocket:
Resolves: https://github.com/microsoft/winget-pkgs/issues/153926
Microsoft Reviewers: Open in CodeFlow

Is there a way to skip this within the inno installer?

Automatic Validation ended with:
(Automated response - build 881.)

@stephengillie
Is there a way to skip this within the inno installer?
image
I already added installer switches, but they don't skip this part.

I don't know.

@wingetbot run

@wingetbot run

@wingetbot run

Verify:

https://github.com/microsoft/winget-pkgs/issues/107639

This package installs and launches normally on a Windows 10 VM.

This package installs and launches normally on a Windows 10 VM.


Remote form without inputs sends corrupt multipart request

vanilla-ujs version: 1.2.0
I'm running into issues with remote forms when running feature tests in Poltergeist. Apparently, in test environment authenticity tokens are not included in (remote) forms. Nevertheless, an empty FormData is passed to LiteAjax which generates an empty multipart request without closing boundary. The corrupt request raises an error in Rack, as shown in the RSpec output below.
I also investigated how jquery-ujs deals with remote forms. For forms with inputs it sends an URL encoded request and without inputs it is just a plain request without body. Besides that, when using jquery-ujs I could add a type: :json to the button_to tag which would send a empty JSON request.
I see a few solutions:

post requests without data (and maybe all post request without files) should be x-www-form-urlencoded
when the FormData object has no values, it should not be sent (just xhr.send() instead of xhr.send(data))
vanilla-ujs should support data-type on the remote form to able to switch to a JSON request

RSpec output:
     1.2) Failure/Error: raise EOFError if eof

          EOFError:
            EOFError
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/multipart/parser.rb:361:in `handle_empty_content!'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/multipart/parser.rb:185:in `on_read'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/multipart/parser.rb:72:in `block in parse'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/multipart/parser.rb:70:in `loop'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/multipart/parser.rb:70:in `parse'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/multipart.rb:52:in `extract_multipart'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/request.rb:472:in `parse_multipart'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/request.rb:335:in `POST'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/method_override.rb:39:in `method_override_param'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/method_override.rb:27:in `method_override'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/method_override.rb:15:in `call'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/runtime.rb:22:in `call'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/middleware/executor.rb:12:in `call'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/middleware/static.rb:136:in `call'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/sendfile.rb:111:in `call'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/railties-<IP_ADDRESS>/lib/rails/engine.rb:522:in `call'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/urlmap.rb:68:in `block in call'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/urlmap.rb:53:in `each'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rack-2.0.1/lib/rack/urlmap.rb:53:in `call'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/capybara-2.8.1/lib/capybara/server.rb:43:in `call'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/puma-3.6.0/lib/puma/server.rb:578:in `handle_request'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/puma-3.6.0/lib/puma/server.rb:415:in `process_client'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/puma-3.6.0/lib/puma/server.rb:275:in `block in run'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/puma-3.6.0/lib/puma/thread_pool.rb:116:in `call'
          # /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/puma-3.6.0/lib/puma/thread_pool.rb:116:in `block in spawn_thread'
          #
          #   Showing full backtrace because every line was filtered out.
          #   See docs for RSpec::Configuration#backtrace_exclusion_patterns and
          #   RSpec::Configuration#backtrace_inclusion_patterns for more information.
          # ------------------
          # --- Caused by: ---
          # Capybara::CapybaraError:
          #   Your application server raised an error - It has been raised in your test code because Capybara.raise_server_errors == true
          #   /usr/local/var/rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/capybara-2.8.1/lib/capybara/session.rb:126:in `raise_server_error!'

Comparison between vanilla-ujs and jquery-ujs

Library
Form inputs
Content-Type request header
Request body

vanilla-ujs
no
Content-Type:multipart/form-data; boundary=----WebKitFormBoundarytlflAqgCb2rxgZF7

vanilla-ujs
yes
Content-Type:multipart/form-data; boundary=----WebKitFormBoundarylncJBPQwE3m4lhEm

jquery-ujs
no
-none-
-none-

jquery-ujs
yes
Content-Type:application/x-www-form-urlencoded; charset=UTF-8

Thanks for great writing. I will try to fix it ASAP.

@hauleth I managed to write a fix, I issued a pull request here: #29.
A minor note:
form.js contains the line:
data[CSRF.param()] = CSRF.token();

This structure does not always work (at least not in Chrome). I believe the recommended syntax is:
data.append(CSRF.param(), CSRF.token());

On the other hand, isn't the input for the authenticity_token already included in the form automatically?


DKIM setup, doesn't stick

Hey,
Great descriptions and all, and I think I've followed all steps, but I seem unable to make a setup that send DKIM signed mails. I've overcome the initial issue with lacking permissions on the volume (exim ran as uid 100, gid 101), and have gotten the key generated (and published a DKIM key in the DNS), at: dkim._domainkey.kbh.mbwarez.dk
My Compose file is as follows:
smtp:
  image: bambucha/exim-relay
  user: exim
  ports:
    - <IP_ADDRESS>:25:25
  volumes:
    - /mnt/systems/configs/mailserver/keys:/dkim
  hostname: mail.kbh.mbwarez.dk
  environment:
    - RELAY_FROM_HOSTS=<IP_ADDRESS>/8:<IP_ADDRESS>/12:<IP_ADDRESS>/16
    - DKIM_KEY_SIZE=1024
    - DKIM_SELECTOR=dkim
    - DKIM_SIGN_HEADERS=Date:From:To:Subject:Message-ID
    - DKIM_DOMAINS=kbh.mbwarez.dk
  restart: always

My log says the following:
# docker-compose up
Starting mailserver_smtp_1
Attaching to mailserver_smtp_1
smtp_1 | 2017-01-10 00:16:29 exim 4.87 daemon started: pid=5, -q15m, listening for SMTP on port 25 (IPv4)
smtp_1 | 2017-01-10 00:16:33 1cQk77-000007-7z <=<EMAIL_ADDRESS>H=(MB-WIN10) [<IP_ADDRESS>] P=esmtp S=326 T="Hi" for<EMAIL_ADDRESS>smtp_1 | 2017-01-10 00:16:34 1cQk77-000007-7z =><EMAIL_ADDRESS><EMAIL_ADDRESS>R=dnslookup T=remote_smtp H=aspmx.l.google.com [<IP_ADDRESS>] C="250 2.0.0 OK<PHONE_NUMBER> l5si123444wju.6 - gsmtp"
smtp_1 | 2017-01-10 00:16:34 1cQk77-000007-7z Completed
^CGracefully stopping... (press Ctrl+C again to force)
Stopping mailserver_smtp_1 ... done

I send the actual mail with a powershell cmdlet from a windows client (as seen in the logs, it all arrives as expected).
What am I doing wrong?
Note: The mails do arrive at my Gmail inbox, the SPF validates, but the mail is with no trace of DKIM signatures.

The issue seemed to solve itself once I started using it in its intended environment.. So that's always something :).


[Question] how to access Web3 Connector on other screens

Hello, i have question on how to use wallet connect methods on diffrent screeens.
lets say we connect wallet on Wallet.tsx page and i want to trigger a transaction on a diffrent screen like Payment.tsx
how to import and use wallet connect on the payment page without having to initialize wallet connect again?
it would be awesome to give example based on the latest update on the example.
thanks

Solved by using the code from latest version.


Update generate_openapi_code.sh

Key Changes:
Modular Functions: The script is now organized into functions for logging actions, compiling TypeSpec, and running Poetry tasks. Logging: Introduced log_action for logging actions and errors with timestamps. This helps track what the script is doing in real-time. Error Handling: Added || { ... } constructs to gracefully handle errors and log them. Optional Poetry Update: The --update-poetry flag is available to update Poetry dependencies before running tasks. If not passed, Poetry runs without updating. Execution Time: Logs the total time taken for the script to execute, making it easier to track performance.

[!IMPORTANT]
Refactor generate_openapi_code.sh to modularize functions, add logging, improve error handling, and introduce optional Poetry update flag.

Modularization:

Split script into functions: log_action, compile_typespec, run_poetry_tasks, and usage.

Logging:

Added log_action() to log actions with timestamps to script.log.
Logs start and end time of script execution.

Error Handling:

Added || { ... } constructs for error handling in compile_typespec and run_poetry_tasks.

Optional Poetry Update:

Introduced --update-poetry flag to optionally update Poetry dependencies.

Misc:

Added usage instructions for script options.

This description was created by  for 543f189fe6ac192bae74f3af511217b842ba1eab. It will automatically update as commits are pushed.

Have you verified if the bash script works correctly? Please post output here that it does and I'd be happy to merge this pr

Duplicate of #547


Training models on SPICE

We still have some time before data generation is complete, but I think this is a good time to start discussing the next stage of the project: creating ready-to-use models trained on SPICE. Here are some of the things we need to discuss.
What architectures do we want to try? My tests so far have used the equivariant transformer in torchmd-net.  What other architectures should we try out?
A related question is what methods of handling charges we want to try?  In my tests so far, I've done it by assigning a different atom type to each combination of element and formal charge.  There are other methods we could try as well, including ones that predict partial charges and include an explicit Coulomb term.
We need to create a test set. We could, of course, just pick a random set of samples from the original dataset to use as our test set, but I think we can do better. I suggest creating several new sets of conformations to separately test how it generalizes in different ways:

New conformations for some molecules present in the training set.
Molecules not present in the training set.
Molecules that are larger than anything in the training set: larger drug molecules, longer peptides, water droplets.
New classes of molecules that are not present in the training set: nucleic acids, lipids, carbohydrates, etc.

I've been running tests training models on a subset of the data.  Here are the architectures I've tried.

Equivariant transformer
NequIP
Allegro

An issue with the latter two, which are both implemented in the same code, is that it requires the whole dataset to be loaded into memory at once.  That limits me to about 250,000 samples.  I've been talking to the developers about how to solve that problem.
All three models generally seem to be able to learn the data.  The best result I've gotten so far is with equivariant transformer, where I've gotten the RMS error on the validation set down to about 10 kJ/mol.  On the other two I've only gotten it down to about 30 kJ/mol.  Don't read anything into that though.  I've only tried default settings on them so far and haven't done any hyperparameter tuning at all.  The important message is that all three architectures basically work.
I also don't see a lot of sign of overfitting.  The validation set error is only slightly worse than the training set error.  That's encouraging, given that this only included three of the six PubChem sets.
To understand the results a bit better, I computed errors for 100,000 randomly chosen samples.  Here are the median, mean, and RMS errors (in kJ/mol)
median: 5.73
mean: 8.18
RMS: 12.85
If I exclude the 1% of samples with the largest errors, they get significantly better:
median: 5.65
mean: 7.54
RMS: 10.21
Given that, and given the large difference between median and RMS, it seems a small fraction of samples with large errors are bringing up the averages.  Molecule size is of course one factor affecting the error, but it doesn't seem to be the main one:

In fact, if we divide the error by sqrt(# atoms) the result is basically flat, suggesting the per-atom errors are uncorrelated and independent of molecule size:

Here are the SMILES strings for the ten samples with the largest errors.  All of these have errors >189 kJ/mol.  Note that several molecules appear multiple times.
[H:14][C:3]#[C:4][C:5]#[C:6][C:9](=[C:2]=[C:10]([H:16])[C:12]1([C:13]([C:11]([C:8](=[O:1])[O:7]1)([H:17])[H:18])([H:20])[H:21])[H:19])[H:15]
[H:14][C:3]#[C:4][C:5]#[C:6][C:9](=[C:2]=[C:10]([H:16])[C:12]1([C:13]([C:11]([C:8](=[O:1])[O:7]1)([H:17])[H:18])([H:20])[H:21])[H:19])[H:15]
[H:13][C:7]([H:14])([H:15])[S:4][C:8]([H:16])([H:17])[C:9]([H:18])([H:19])[C:5](=[N:1][H:10])[P:6]([O:2][H:11])[O:3][H:12]
[H:11][C:8]1=[N:4][C:9]2=[N:5][N:2]=[N:3][C:7](=[O:1])[C:10]2=[N:6]1
[H:10][C:9]([C:8](=[C:6]=[C:7]([Cl:1])[Cl:2])[Cl:3])([Cl:4])[Cl:5]
[H:11][C:3]1=[C:1]=[C:5]([C:9]([C:10]([C:6](=[C:2]=[C:4]([C:8]([C:7]1([H:15])[H:16])([H:17])[H:18])[H:12])[H:14])([H:21])[H:22])([H:19])[H:20])[H:13]
[H:11][C:8]1=[N:4][C:9]2=[N:5][N:2]=[N:3][C:7](=[O:1])[C:10]2=[N:6]1
[H:11][C:3]1=[C:1]=[C:5]([C:9]([C:10]([C:6](=[C:2]=[C:4]([C:8]([C:7]1([H:15])[H:16])([H:17])[H:18])[H:12])[H:14])([H:21])[H:22])([H:19])[H:20])[H:13]
[H:11][C:8]1=[N:4][C:9]2=[N:5][N:2]=[N:3][C:7](=[O:1])[C:10]2=[N:6]1
[H:11][C:3]1=[C:1]=[C:5]([C:9]([C:10]([C:6](=[C:2]=[C:4]([C:8]([C:7]1([H:15])[H:16])([H:17])[H:18])[H:12])[H:14])([H:21])[H:22])([H:19])[H:20])[H:13]

For comparison, here are the ten with the smallest errors.  All of these have errors <0.001 kJ/mol.
[H:17][N:15]([H:18])[C:7](=[O:1])[c:13]1[c:12]([c:14]([c:11]([c:9]([c:10]1[Cl:4])[Cl:3])[Cl:5])[C:8](=[O:2])[N:16]([H:19])[H:20])[Cl:6]
[H:20][C:12](=[C:11]([H:19])[C:13](=[C:15]1[C:9](=[N:3][O:4][C:7]1=[O:1])[C:17]([H:25])([H:26])[H:27])[H:21])[C:14]2=[C:10]([O:6][N:2]=[C:8]2[C:16]([H:22])([H:23])[H:24])[O:5][H:18]
[H:20][c:4]1[c:5]([c:7]([c:9]([c:8]([c:6]1[H:22])[H:24])[O:3][C:18]([C:13]([H:32])([H:33])[H:34])([C:14]([H:35])([H:36])[H:37])[C:17]([C:12]([H:29])([H:30])[H:31])([N:10]([H:25])[C:16]([H:40])([H:41])[C:15]([H:38])([H:39])[O:1][C:11]([H:26])([H:27])[H:28])[O:2][H:19])[H:23])[H:21]
[H:37][C:22]1([C:10](=[N:5][N:17]([C:8](=[O:2])[C:21]1([H:35])[H:36])[C:19]([H:30])([H:31])[C:9]2=[N:4][C:13]3=[C:12]([N:15]2[H:26])[C:11](=[C:14]([C:7](=[O:1])[N:16]3[C:18]([H:27])([H:28])[H:29])[C:23]([H:39])([H:40])[C:24]([H:41])([H:42])[C:20]([H:32])([H:33])[H:34])[O:6][H:25])[Cl:3])[H:38]
[H:11][C:6]1([C:4]([N:3]([C:5]1([H:9])[H:10])[C:2]#[N:1])([H:7])[H:8])[H:12]
[H:13][N:11]([H:14])[c:9]1[c:8]([c:10]([c:7]([c:5]([c:6]1[F:2])[F:1])[F:3])[N:12]([H:15])[H:16])[F:4]
[H:10][C:3]1([C:5]([C:9]2([C:6]([C:4]([C:8]1([C:7]2([H:18])[H:19])[H:20])([H:12])[H:13])([H:16])[H:17])[N+:2]#[C-:1])([H:14])[H:15])[H:11]
[H:14][C:5]1=[N:1][C:7]2=[C:8]([N:12]1[H:18])/[C:9](=[N:3]\\[O:4][C:13]([H:19])([H:20])[H:21])/[N:2]=[C:6]([N:11]2[H:17])[N:10]([H:15])[H:16]
[H:20][C:12](=[C:11]([H:19])[C:13](=[C:15]1[C:9](=[N:3][O:4][C:7]1=[O:1])[C:17]([H:25])([H:26])[H:27])[H:21])[C:14]2=[C:10]([O:6][N:2]=[C:8]2[C:16]([H:22])([H:23])[H:24])[O:5][H:18]
[H:17][C:6](=[N+:4]=[N-:1])[C:5](=[O:2])[C:12]1([C:15]2([C:8]([C:13]3([C:7]([C:14]([C:9]2([H:22])[H:23])([C:11]([C:16]1([C:10]3([H:24])[H:25])[Br:3])([H:26])[H:27])[H:30])([H:18])[H:19])[H:29])([H:20])[H:21])[H:31])[H:28]

One thing that does not seem to account for the difference is the presence of charges.  I was worried that my simple method of handling them (using different atom types for different formal charges) would lead to large errors on charged or polar molecules.  But none of the samples with the largest errors have any nonzero charges, whereas a couple of the samples with the lowest errors do.

Thanks Peter. For the molecules with the biggest errors, it might be worth checking the electronic structure output and/or recomputing the energies using a different code since although ground state DFT of these types of molecules doesn't fail that often it does sometimes happen and with a data set this large it wouldn't be surprising to me if some calculations had issues.

I looked a bit more into the molecules with very large errors.  Here's a plot comparing the reference and predicted energies for [H:11][C:8]1=[N:4][C:9]2=[N:5][N:2]=[N:3][C:7](=[O:1])[C:10]2=[N:6]1.  Conformations are sorted by error, so the most accurate ones are on the left and the least accurate ones on the right.

There are only a few conformations where it's wildly inaccurate.  For most conformations, the energies are consistently a little too large but overall not too bad.  With more data and/or training, it's likely the model could learn this.  Also notice that the very inaccurate conformations are the highest energy ones.  Maybe that's why the predictions on other conformations are consistently too high: it's compensating to try to get the highest energy ones not quite as far off?
Now compare to the energies for [H:11][C:3]1=[C:1]=[C:5]([C:9]([C:10]([C:6](=[C:2]=[C:4]([C:8]([C:7]1([H:15])[H:16])([H:17])[H:18])[H:12])[H:14])([H:21])[H:22])([H:19])[H:20])[H:13].

In this case, most energies are totally wrong.  There are about 15 conformations at the left where it's not so bad, but it isn't anywhere close to having learned to predict this molecule.  Also notice that there's no correlation between energy and error.  Unlike the previous molecule, very low energy conformations are just as likely to be predicted incorrectly as very high energy ones.

Can you share the TorchMD-ET input file?

The config file is attached.
config.yaml.txt

I've been investigating this further with @YuezhiMao and @tmarkland.  A first possibility we needed to eliminate was that the DFT energies were incorrect, for example because it converged to an excited state rather than the ground state, or perhaps because of a bug in Psi4.  To test that, Yuezhi repeated the calculations for the second molecule above using Q-Chem with a few different methods: B3LYP-D3(BJ), wB97M-V, and RI-MP2.  The agreement was excellent.  So it doesn't seem to be a problem with the reference data.  The model just had trouble learning certain molecules.
I identified every sample for which the error was >100 kJ/mol.  There are 146 such samples out of more than 100,000 that I computed, so less that 0.15%.  For comparison, more than 10% of samples have errors below 1 kJ/mol.  Furthermore, those 146 samples are for just 30 molecules, and many of those have only 1 or 2 samples with errors above 100 kJ/mol.  There are 17 molecules with more than 2 conformations with very large errors.  Here they are.
[H:11][C:3]1=[C:1]=[C:5]([C:9]([C:10]([C:6](=[C:2]=[C:4]([C:8]([C:7]1([H:15])[H:16])([H:17])[H:18])[H:12])[H:14])([H:21])[H:22])([H:19])[H:20])[H:13]
[H:17][c:7]1[c:9]([c:13]2=[N:3][S:6][N:4]=[c:14]3[c:16]2[c:15]4[c:11]1=[N:1][S:5][N:2]=[c:12]4[c:8]([c:10]3[H:20])[H:18])[H:19]
[Na+:2].[I-:1]
[H:8][C:2](=[C:1]=[C:3]([C:5](=[C:4]([H:10])[H:11])[C:7]([H:15])([H:16])[H:17])[C:6]([H:12])([H:13])[H:14])[H:9]
[H:6][C:4](=[C:2]=[C:5]([H:8])[C:3]#[N:1])[H:7]
[H:14][C:3]#[C:4][C:5]#[C:6][C:9](=[C:2]=[C:10]([H:16])[C:12]1([C:13]([C:11]([C:8](=[O:1])[O:7]1)([H:17])[H:18])([H:20])[H:21])[H:19])[H:15]
[H:10][C:2](=[C:1]=[C:3]([C:8]1([C:4]([C:5]1([H:14])[H:15])([H:12])[H:13])[H:20])[C:9]2([C:6]([C:7]2([H:18])[H:19])([H:16])[H:17])[H:21])[H:11]
[H:4][C:3](=[S:2]=[O:1])[H:5]
[H:16][C:6](=[C:3]=[C:7]([H:17])[C:15]([C:10]([H:24])([H:25])[H:26])([C:11]([H:27])([H:28])[H:29])[C:14]([H:34])([H:35])[C:13]([H:32])([H:33])[C:12]([H:30])([H:31])[C:5](=[O:2])[C:9]([H:21])([H:22])[H:23])[C:4](=[O:1])[C:8]([H:18])([H:19])[H:20]
[H:8][C:5]([H:9])([H:10])[C:3](=[S:2]=[O:1])[N:4]([H:6])[H:7]
[H:16][c:6]1[c:7]([c:9]([c:11]2=[C:5]([C:3](=[C:1]=[C:2]([H:12])[H:13])[C:4](=[c:10]2[c:8]1[H:18])[H:14])[H:15])[H:19])[H:17]
[H:10][C:9]([C:8](=[C:6]=[C:7]([Cl:1])[Cl:2])[Cl:3])([Cl:4])[Cl:5]
[O:5]([P:6]([F:1])[F:2])[P:7]([F:3])[F:4]
[H:18][c:8]1[c:7]([c:9]([c:11]2[c:12]([c:10]1[H:20])[C:6](=[N:2][O:4]2)[C:13]([H:21])([H:22])[S:14](=[N:3][H:15])(=[O:1])[O:5][H:16])[H:19])[H:17]
[C:5](=[C:6]([F:1])[F:2])=[C:7]([F:3])[F:4]
[H:18][c:8]1[c:9]([c:11]([c:13]([c:12]([c:10]1[H:20])[H:22])[C:6](=[C:5]=[C:7]([H:17])[S:14](=[O:1])[C:15]([Cl:2])([Cl:3])[Cl:4])[H:16])[H:21])[H:19]
[H:11][C:8]1=[N:4][C:9]2=[N:5][N:2]=[N:3][C:7](=[O:1])[C:10]2=[N:6]1

The motif =C=C appears in 10 of those 17 molecules.  That seems to be a particularly difficult pattern for it.  =S=O appears in two others.
The most puzzling one is the Na+ I- ion pair.  That ought to be a very easy case for it to learn.  For comparison, K+ I- also has fairly large errors (from 25 to 91 kJ/mol), but Na+ Cl- has much lower errors (between 2.7 and 26 kJ/mol).  Possibly we just need to generate more training data for these simple ions, especially I-.

For what it's worth, the dataset contains 7215 occurrences of Cl-, but only 3936 of I-.  That easily might (or might not) account for the difference in accuracy.

Looking at the plots of energy vs. distance for different pairs of monatomic ions, most of them look something like this:

It does a good job at short distances, but becomes significantly less accurate at longer distances.   I don't think this reflects a limitation of the model.  It uses a cutoff of 10 A, so it should have no trouble at only a 3 A separation.  I suspect it's just a lack of training data.  Some are a little better than others, but the basic pattern is the same for nearly all of them.
The two exceptions are K+/I- and Na+/I-, which it just completely failed to learn.

This too probably just reflects insufficient training data.  I think we'll want to add more data for these simple pairs, especially at larger separations.  They'll be super cheap to calculate since they're only two atoms each and there won't be very many of them.

I generated some more training data for ion pairs and trained a new model.  The result is enormously improved.

I'll open a PR adding a new dataset with lots of ion pairs.

I'd like to investigate other ways of handling charges.  Any suggestions for methods to try?  I know @jchodera is fond of the method described in https://www.nature.com/articles/s41467-020-20427-2.  It consists of these steps.

The neural network predicts an electronegativity for each atom.
Solve a system of equations to get a partial charge for each atom.
Include an explicit Coulomb interaction between the partial charges.

A problem with this method is that step 2 scales very badly with the number of atoms.  Instead of directly solving the system of equations, perhaps we could use an iterative solver and hardcode a small, fixed number of iterations?
What else would be good to try?

What about predicting charge density in space as an option ?
On Wed, Jun 8, 2022 at 3:18 PM Peter Eastman @.***>
wrote:

I'd like to investigate other ways of handling charges. Any suggestions
for methods to try? I know @jchodera https://github.com/jchodera is
fond of the method described in
https://www.nature.com/articles/s41467-020-20427-2. It consists of these
steps.

The neural network predicts an electronegativity for each atom.
Solve a system of equations to get a partial charge for each atom.
Include an explicit Coulomb interaction between the partial charges.

A problem with this method is that step 2 scales very badly with the
number of atoms. Instead of directly solving the system of equations,
perhaps we could use an iterative solver and hardcode a small, fixed number
of iterations?
What else would be good to try?
—
Reply to this email directly, view it on GitHub
https://github.com/openmm/spice-dataset/issues/24#issuecomment-1150470411,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB3KUOTW2ZAPEAP6TGLHDCLVOEL5DANCNFSM5VZB3V6A
.
You are receiving this because you commented.Message ID:
@.***>

How would that work?  Is there a paper describing it?

No paper that I know. The idea would be to leave the short range to the NNP
and go to Ewald summation for long range. Would that be doable?
On Wed, Jun 8, 2022 at 5:19 PM Peter Eastman @.***>
wrote:

How would that work? Is there a paper describing it?
—
Reply to this email directly, view it on GitHub
https://github.com/openmm/spice-dataset/issues/24#issuecomment-1150538688,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB3KUOXKJOXMBUTB52OIPZLVOEZ7JANCNFSM5VZB3V6A
.
You are receiving this because you commented.Message ID:
@.***>

In principle, though only for periodic systems of course.  In a sense that's what the other method does.  If you predict partial charges for each atom, you can use PME for the long range part.  The main NNP is then learning just a correction to it.  It sounds like you're thinking of something a bit more complicated though, where you directly predict a charge distribution rather than just atomic charges?

Yes, exactly. Partial charges are a trick.
On Wed, Jun 8, 2022 at 5:51 PM Peter Eastman @.***>
wrote:

In principle, though only for periodic systems of course. In a sense
that's what the other method does. If you predict partial charges for each
atom, you can use PME for the long range part. The main NNP is then
learning just a correction to it. It sounds like you're thinking of
something a bit more complicated though, where you directly predict a
charge distribution rather than just atomic charges?
—
Reply to this email directly, view it on GitHub
https://github.com/openmm/spice-dataset/issues/24#issuecomment-1150556428,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB3KUOSMKG6KMUIHEOB2QLLVOE525ANCNFSM5VZB3V6A
.
You are receiving this because you commented.Message ID:
@.***>

Model-building scripts and trained models are now made available in https://github.com/openmm/spice-models


PointSize and PointStep don't belong to MLLine

PointSize and PointStep are the properties of the brush, they shouldn't be cached in the MLLine. MLLine should store force but not the size as it should be able to be rendered with any brush. So when LineStrip calculates vertex size It should take the force of the MLLine and size of the brush. It's much more flexible and architecturally correct IMO.
The current way it embeds part of the brush properties and the line cannot be reused to be rendered to another target texture with another brush.

Brush should only be used when rendering the strip, not when assembling it. It's much better to be able to change the brush of the entire strip, not the individual fragments of it. I cannot imagine someone changing the brush in the middle of the stroke.

Not agree. All lines and strips are not designed for reusing, they are designed for persistance. these lines should not be changed to another apperance once they are painted. So the saved data can be transformed to another device and recovered to what it is. And the color for eche fragments of a line strip makes it posiable to paint gradient lines.

I see your point, thank you! Though I would prefer vector-like behaviour where one could change the style of the strip after drawing it.


Add support for GitHub actions

Add ci file for supporting Github Actions

Sometimes test failed with error such as here
Link on success ci jobs you can see here

Yeah, it suffers the same issue as here https://github.com/spiral/roadrunner/issues/194 :(
We need to rotate RPC ports in tests.
Overall look good! Thank you

I'll merge it after https://github.com/spiral/roadrunner/issues/194 will be complete, or we have a high chance of false errors which will be annoying to verify.

I'll merge it after #194 will be complete, or we have a high chance of false errors which will be annoying to verify.

I will try to research this problem

Thank you. Ping me on Discord if you need some assistance. It will require Golang knowledge.

@wolfy-j, problem with failed tests was resolved, how do you pass repo-token for codecov.io?
Link on last ci  pipeline. Sending codecoverage fails because repo-token is not used
Codecov has action for using in existing workflow https://github.com/codecov/codecov-action

Hi, the codecov token is passed automatically by travis.ci. It seems that Codecov does not support Github actions yet. I would disable code-coverage push on Github for now and leave coverage analysis from travis only.

FYI, the issue with ports not fixed, it's just rare to occur. :( We have to fix the golang test in order to fix it.

I mean that problem with failed tests because i change flag occasionally in ci file Github Actions

Hi, the codecov token is passed automatically by travis.ci. It seems that Codecov does not support Github actions yet. I would disable code-coverage push on Github for now and leave coverage analysis from travis only.

GIthub Actions doesn't include in support ci systems, but i can use if condition in step in ci
For example, as here

@wolfy-j i add if condition for code coverage

let me rerun travis tests and merge it


Key master does not work while textarea is focused

So I want to be able to press ctrl + s to save a file but I find that I can't do that while the <textarea> element is focused.

Hey @tcaer, check out this section on filtering key presses. That's the default behavior - you'll have to add a little bit more code to override that default behavior.


Target Offset supported?

Hi, is this wrapper support target offset? If someone want to change default target offset?

Please ignore this question, I found it, its already included.

Woot :D


Select overlay displayed in wrong place

Bug, feature request, or proposal:
Bug
What is the expected behavior?
Transition of opening mat-select should be smooth and not distorted
What is the current behavior?
When mat-select is nested inside mat-card it is affected by font-size styling applied to card. Visually it looks fine, but when a user clicks on a select an overlay is placed a few pixels below and interface looks jumpy.
What are the steps to reproduce?
Put mat-select inside mat-card and try open it
https://stackblitz.com/edit/angular-material2-issue-oyexyr
What is the use-case or motivation for changing an existing behavior?
Polishing an interface
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Chrome, Safari (probably more of them)
Is there anything else we should know?
--

I wasn't able to reproduce it with the latest version. Closing.

there is still a little shift on material v9.2.4...
See this https://stackblitz.com/edit/components-issue-9c7ddi?file=src%2Fstyles.scss
Compare opening the select overlay when you have selected value (like Apple) and then uncomment a line #21 in styles.scss - then the overlay text fits perfectly over the one inside the select input

I see what you mean, but unfortunately it's very difficult to guarantee that the panel will be 100% aligned with the text, especially when dealing with smaller fonts. We may also remove this behavior altogether in the future since, from what I remember, it's not in the Material design spec anymore.

understood, for my use case, I can fix with this single line of style as we have a fixed font size. Thanks for your reply


Cannot read property 'transports' of undefined

Getting following error after updating to 1.0.0-rc-5
/node_modules/@mean-expert/loopback-component-realtime/dist/drivers/io.driver.js:19
        this.server = server(options.server, { transports: options.driver.options.transports });
                                                                                ^

TypeError: Cannot read property 'transports' of undefined
    at IODriver.connect (/Users/joaoribeiro/Documents/Projects/seeds/api-seed/node_modules/@mean-expert/loopback-component-realtime/dist/drivers/io.driver.js:19:82)
    at Function.RealTime.connect (/Users/joaoribeiro/Documents/Projects/seeds/api-seed/node_modules/@mean-expert/loopback-component-realtime/dist/index.js:35:25)
    at EventEmitter.<anonymous> (/Users/joaoribeiro/Documents/Projects/seeds/api-seed/node_modules/@mean-expert/loopback-component-realtime/dist/index.js:28:26)
    at emitOne (events.js:101:20)
    at EventEmitter.emit (events.js:188:7)
    at Server.<anonymous> (/Users/joaoribeiro/Documents/Projects/seeds/api-seed/server/server.js:66:9)
    at Server.g (events.js:291:16)
    at emitNone (events.js:91:20)
    at Server.emit (events.js:185:7)
    at emitListeningNT (net.js:1288:10)
    at _combinedTickCallback (internal/process/next_tick.js:77:11)
    at process._tickDomainCallback (internal/process/next_tick.js:128:9)
    at Module.runMain (module.js:606:11)
    at run (bootstrap_node.js:393:7)
    at startup (bootstrap_node.js:150:9)
    at bootstrap_node.js:508:3

current config:
  "@mean-expert/loopback-component-realtime": {
    "debug": false,
    "auth": true,
    "driver": {
      "name": "socket.io"
    },
    "modules": [
      "IO",
      "PubSub",
      "FireLoop",
      "WebRTCSignaler"
    ]
  }

@JonnyBGod it seems that the Object.assign I use to add your custom settings to the default, removes the default options from the component.
I'll see how to internally fix that, but for now you just need to update your settings as follows:
  "@mean-expert/loopback-component-realtime": {
    "debug": false,
    "auth": true,
    "driver": {
      "name": "socket.io",
      "options": {}
    },
    "modules": [
      "IO",
      "PubSub",
      "FireLoop",
      "WebRTCSignaler"
    ]
  }
}

For now by adding an empty options object, the Object.assign won't remove the default settings from the component, so there is no need you pass any options, it is basically to avoid the default options to be removed.
Cheers
Jon

Great thanks, temporary fix works.
Will leave the issue open until it is fully fixed for others reference.


✨ Support template-base changelog maintenance

Summary
The current ticket request to enhance PTB in order to support users to maintain the changelog or their application projects.
Details
Proposed work-flow for starting to work on a new version of the current application

user assigns new version in pyproject.toml and calls

either poetry run nox -s fix
or poetry run version-check <path/version.py> --fix

PTB

updates file doc/changes/changelog.md
creates file doc/changes/unreleased.md with content from template (see below)

Proposed work-flow for finishing and releasing a new version of the current application

PTB

validates content of file doc/changes/unreleased.md (specification: TBD) and reports potential findings
renames file doc/changes/unreleased.md to  file doc/changes/changes_<version>.md using the version from  file pyproject.toml.
sets release date (if possible / appropriate)

maybe this needs to be done in a later step?

updates file doc/changes/changelog.md

Proposed template, see https://github.com/exasol/notebook-connector/blob/main/doc/changes/changes_0.2.2.md
# <project-name from README.md> <version>, released t.b.d

Code name:

## Summary

<please enter summary here>

<!-- Sections: Changes, Features, Bugfixes, Refactorings, Documentation, Security -->
## Changes

* ISSUE_NUMBER: description

Background & Context
Automation, convenience, reduce manual work, increase quality, unify workflows, provide guidance for developers not familiar with processes and tools in Exasol Product Integration Team.
Examples
Sample repo already using the PTB: https://github.com/exasol/notebook-connector
References
Compare workflows with project-keeper and release-droid.

Closing this issue, due to the fact that most of the mentioned functionality is provided by the newly added nox -s prepare-release -- <version> tasks.


Create an npm types package for public extension API

So that it's easier to keep track of any changes in the Python API.

Verification steps:
Follow the steps in https://github.com/microsoft/vscode-python/wiki/Python-Environment-APIs#extension-api-usage and verify any one of examples provided there.


[1606] raise error when sync to sac fails

Context
We're getting errors when we try to sync a course with search and compare.
Changes proposed in this pull request
Ensure an error is raised when we try to sync a course so we have a better understanding of what's gone wrong.
Checklist

[ ] Make sure all information from the Trello card is in here
[ ] Attach to Trello card
[ ] Rebased master
[ ] Cleaned commit history
[ ] Tested by running locally

 Expose errors when sync/publish to S&C fails


Add a Python version check to helper scripts

The customer-visible scripts gfxrecon.py, gfxrecon-capture.py, and gfxrecon-capture-vulkan.py should do a Python version check early in the script.
Our internal users have had issues where they were using an earlier version of Python than the script required, and the default error message isn't very helpful, e.g.:
>  python C:\VulkanSDK\<IP_ADDRESS>\Bin\gfxrecon.py capture-vulkan D:\VulkanDev\SaschaWillemsVulkan\build\bin\Debug\bloom.exe
Executing program D:\VulkanDev\SaschaWillemsVulkan\build\bin\Debug\bloom.exe
Traceback (most recent call last):
  File "C:\VulkanSDK\<IP_ADDRESS>\Bin\gfxrecon-capture-vulkan.py", line 339, in <module>
    result = subprocess.run(args.program_and_args, capture_output=True)
  File "C:\Users\dustin\AppData\Local\Programs\Python\Python36\lib\subprocess.py", line 403, in run
    with Popen(*popenargs, **kwargs) as process:
TypeError: __init__() got an unexpected keyword argument 'capture_output'
PS C:\Users\dustin> python C:\VulkanSDK\<IP_ADDRESS>\Bin\gfxrecon-capture-vulkan.py D:\VulkanDev\SaschaWillemsVulkan\build\bin\Debug\bloom.exe
Executing program D:\VulkanDev\SaschaWillemsVulkan\build\bin\Debug\bloom.exe
Traceback (most recent call last):
  File "C:\VulkanSDK\<IP_ADDRESS>\Bin\gfxrecon-capture-vulkan.py", line 339, in <module>
    result = subprocess.run(args.program_and_args, capture_output=True)
  File "C:\Users\dustin\AppData\Local\Programs\Python\Python36\lib\subprocess.py", line 403, in run
    with Popen(*popenargs, **kwargs) as process:
TypeError: __init__() got an unexpected keyword argument 'capture_output'

We should do such a test.  We're somewhat lucky that the first Google search result for unexpected keyword argument 'capture_output' is a Stack Overflow post noting that Python 3.7 is the first version to support capture_output.
What does the Pythonic version of the test look like?

Something like:
if sys.version_info() < (3, 7):
    log.error("Python 3.7 or better is required; you're using: %s", sys.version)
    sys.exit(1)

It should add in all python code? or only gfxrecon.py?

3.7 was released in 2018.  3.8 was released in 2019.  We assume Visual Studio 2019, so I suggest we might consider assuming Python 3.8.
ff707ac3 added code to the generators to make them compatible with < 3.9, so it's possible 3.8 is just what I knew worked on my machine at the time.  The generators may very well also work with 3.7.
CONTRIBUTING.md has been updated several times in 2022 and 2023 according to the git log.  I more-or-less trust it to be up to date.
I don't immediately see a duplicate section.  If you message me with the section I'll update it and push it and update the copyright.

The generators require at least Python 3.8.
Generating generated_vulkan_enum_to_json.cpp
Traceback (most recent call last):
  File "/home/lunarg/brad/gfxreconstruct/framework/generated/vulkan_generators/gencode.py", line 50, in <module>
    from vulkan_decoder_body_generator import VulkanDecoderBodyGenerator, VulkanDecoderBodyGeneratorOptions
  File "/home/lunarg/brad/gfxreconstruct/framework/generated/vulkan_generators/vulkan_decoder_body_generator.py", line 25, in <module>
    from base_generator import BaseGenerator, BaseGeneratorOptions, write
  File "/home/lunarg/brad/gfxreconstruct/framework/generated/vulkan_generators/base_generator.py", line 92
    def removesuffix(self: str, suffix: str, /) -> str:
                                             ^
SyntaxError: invalid syntax


Extend getAppOriginto support x-forwarded-host header in a non-breaking change fashion

Description
Issues: https://github.com/SalesforceCommerceCloud/pwa-kit/issues/1257
TLDR: Retail React App uses getAppOrigin to build links, on server side, it returns the value of process.env.EXTERNAL_HOSTNAME which is an MRT hostname and by pass the original host.
Solution
When CDN is stacked in front of Pwa kit/MRT, the CDN will forward a header x-forwarded-host that contains the origin host. The solution in this PR is to extend getAppOrigin to take that value into the account.
To make it in a non-breaking fashion, a flag useXForwardedHost is introduced in the app configuration (default to false). When it is enabled, getAppOrigin will return the value of x-forwarded-host from request header.

Types of Changes

[ ] Bug fix (non-breaking change that fixes an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Documentation update
[ ] Breaking change (could cause existing functionality to not work as expected)
[x] Other changes (non-breaking changes that does not fit any of the above)

Breaking changes include:

Removing a public function or component or prop
Adding a required argument to a function
Changing the data type of a function parameter or return value
Adding a new peer dependency to package.json

Changes

(change1)

How to Test-Drive This PR

With useXForwardedHost enabled:
You can't test this locally since it needs to have CDN that forwards the req headers. I've uploaded a bundle to this MRT env https://www.phased-launch-testing.com/ that has CDN set up as intended

Visit https://www.phased-launch-testing.com/. Make sure it is deployed with bundle

Check the client and server both returns the value of origin host which is https://www.phased-launch-testing.com not https://scaffold-pwa-bjnl-prd.mobify-storefront.com/
Client: https://www.phased-launch-testing.com/
Server https://www.phased-launch-testing.com/?__server_only=1

With useXForwardedHost disabled:
Deployed to https://www.phased-launch-testing.com/ with bundle

After it finished deploying, Visit https://www.phased-launch-testing.com/ and https://www.phased-launch-testing.com?__server_only=1. You will notice getAppOrigin on server will return https://scaffold-pwa-bjnl-prd.mobify-storefront.com/

Checklists

General

[ ] Changes are covered by test cases
[ ] CHANGELOG.md updated with a short description of changes (not required for documentation updates)

Accessibility Compliance
You must check off all items in one of the follow two lists:

[ ] There are no changes to UI

or...

[ ] Changes were tested with a Screen Reader (iOS VoiceOver or Android Talkback) and had no issues
[ ] Changes comply with WCAG 2.0 guidelines levels A and AA
[ ] Changes to common UI patterns and interactions comply with WAI-ARIA best practices

Localization

[ ] Changes include a UI text update in the Retail React App (which requires translation)

If a client project wanted to use other x-forwarded-* headers, they can take a similar approach as this (by adding an express app in ssr.js), correct?

Technically, yes but they have to be aware how it can be consumed in Retail. The way it is atm is to pass x-forwarded-* headers through a process.env variable. Then in Retail App, they need to create a logic to consume it on server only, client side can't access process.env. A little more work, but it is possible to do it user-land only.

Is this something we should document?

if you meant other headers, I don't think we should document since it would encourage partners to create more custom code. I am not aware if there is any customer who needs access to another x-forwarded-* headers. When they do, we can start the work to add it in here and provide a util to consume the headers like getAppOrigin
For the use of x-forwarded-host, I've added a comment in the app config for it. See here

Thanks @alexvuong . I think the changes look fine. Let me know once the test-only line of code has been removed and I can give this PR a +1.


Why are there multiple npm modules that seem to be identical?

I'm a bit confused on the differences between some npm packages, they seem so similar:

vss-web-extension-sdk (this repository)
azure-devops-extension-sdk
azure-devops-extension-api

Less confusing, but still a bit confusing...

azure-devops-node-api
azure-devops-ui (npm package exists, but github repo doesn't?)

Is there any ETA when we extension developers should switch to the azure-devops-* packages?
I see that the vss-web-extension-sdk is still on M141, while the azure-devops-* are on M147.


Add Meson build definition

This adds a Meson build definition to this project, to allow projects using Meson to easily use it, and to make packaging undeaD in Linux distributions like Debian and Fedora much easier.
(Meson is already well supported in Debian, we need to have D include files installed properly, and having a pkg-config file is very useful to help other tools find the library when building)
The build can be tested by installing Meson, then running:
mkdir b && cd b
meson ..
ninja
DESTDIR=/tmp/test_install ninja install

You can learn more about Meson here: http://mesonbuild.com/

As mentioned on https://github.com/biod/BioD/issues/26, I think

it would be better to use wildcards here as undead doesn't get much love from a maintenance perspective.
it would be awesome to check the Meson build automatically on Travis

Testing it with Travis would mean dropping the sudo: false flag, since we will need to pull a more recent Meson version (the ones in Trusty or Precise, which Travis supports, don't have D support). While we can do that for Meson, a newer Meson will require a newer Ninja - and with a newer Ninja we'll have to have sudo to install dependencies (in which case we could just as well go all-in and switch to building in a Xenial Docker container).

Testing it with Travis would mean dropping the sudo: false flag, since we will need to pull a more recent Meson version (the ones in Trusty or Precise, which Travis supports, don't have D support). While we can do that for Meson, a newer Meson will require a newer Ninja - and with a newer Ninja we'll have to have sudo to install dependencies (in which case we could just as well go all-in and switch to building in a Xenial Docker container).

There seems to be another way without the Docker container (I am not sure how long the provisioning on Travis takes) by directly download a newer ninja binary:
https://github.com/mesonbuild/meson/wiki/Continuous-Integration

I found a way to have the Meson build work without sudo or Docker in Travis :-)
This should work nicely.

Sorry, I don't understand this PR.
I understand that undeaD can be used as a source library without requiring any particular build tool (rdmd would work), but I see there are also makefiles and a dub.json file. So, this raises some questions:

Who will be maintaining this file in the future? I don't think a lot of D users use the build system in question here, and every new build system added adds to the maintenance burden.
Let's say that tomorrow someone contributes a CMake build file. The next day, another PR for another build system or package manager, and so on. Clearly we can't accept every such contribution because it would be impossible to maintain, so then how does one decide which build systems are worth supporting and which aren't?

IMHO, I think we are good the way things are. There are a few build tools/systems which are common across D projects (Make, Dub, rdmd) and supporting those is sufficient for official / semi-official projects. If there is interest in making Meson more popular for D projects, I think this is the wrong place to start; it would have to be either the top (DMD/Phobos/Druntime) or the bottom (great popularity among D users' projects). If there is desire to support more build systems, this can be done in a separate repository tracking this one, which delimits the maintenance burden according to the maintainers' interests better.

undeaD can be used as a source library without requiring any particular build tool

This is frowned upon by distro policy - we would need to justify doing that, which is annoying. Even static libraries are a bad thing, but due to D's ABI instability having a static lib is more justified.

Who will be maintaining this file in the future? I don't think a lot of D users use the build system in question here, and every new build system added adds to the maintenance burden.

As long as the package is in Debian, you can count on us fixing issues, since we want to have it build. In any case, except for adding new files to the meson.build file list, no other maintenance needs to be done.

Let's say that tomorrow someone contributes a CMake build file. The next day, another PR for another build system or package manager, and so on. Clearly we can't accept every such contribution because it would be impossible to maintain, so then how does one decide which build systems are worth supporting and which aren't?

If someone added cmake, we would happily use that. What we want from the build system is:

to build a static and/or dynamic library for the D code
install it to a system path to be found by the linker (`/usr/lib//``at Debian)
to create a pkg-config file so other build systems and makefiles can discover the software and apply the appropriate build flags to find the include files and library
to allow us to do a plain build without predefined build flags to have us select the compiler flags explicitly
ideally perform a splitbuild to not kill the build slaves (less of an issue with D)
work with GDC/LDC

If there is any one such buildsystem doing the job and providing all requirements, we are happy and don't really care which one it is (it should be packaged in Debian though ^^). The install requirements aren't even strictly necessary, but the reduce the amount of work packaging this software is for us.
So, in general I don't care about the buildsystem, if there is just any one working there, I am happy - I just find Meson to be particularly easy to work with compared to cmake+D and Automake+D.

There are a few build tools/systems which are common across D projects (Make, Dub, rdmd) and supporting those is sufficient

No. Rdmd isn't even in Debian yet, dub doesn't work for distro packaging at least until a lot of its bugs are fixed (no write to home, install missing, discover local packages and global locations, use shared libraries instead of building everything from source, etc.) and Makefiles don't provide all features unless someone adds all features manually (which is possible, but not work I want to do).

If there is interest in making Meson more popular for D projects

Nah, this is just to scratch an itch - if someone writes a cmake build definition, or any other solution, we're happy too. DMD can't be packaged in Debian (non-free) and the other interesting pieces (runtime/phobos) are in LDC and GDC which provide Automake and cmake buildscripts, so there is not much need to add another buildsystem if the existing one is sufficient.
In any case, even if you would not accept this patch, we will patch it in downstream to be able to build BioD in Debian (which is Andreas' goal here).
FTR: https://anonscm.debian.org/git/debian-med/libundead.git

Thanks for the explanation. Could you please elaborate why the build definition needs to be in the project's source tree, and not part of the distro's package specification? For example, in the case of Arch Linux, the package build instructions (the PKGBUILD file) is expected to reside in ABS or AUR, not the project's source tree.
Also, would it be reasonable to just improve the makefiles to handle whatever's missing there for Debian packaging?

Rdmd isn't even in Debian yet

I was surprised by this. rdmd definitely needs to be packaged a lot more than, e.g., Dustmite.

Thanks for the explanation. Could you please elaborate why the build definition needs to be in the project's source tree, and not part of the distro's package specification?

Because it's not distro-specific. Anyone can use the Meson build file, even Fedora and Arch might want it, while a debian/rules file is generally only useful in Debian and therefore doesn't need to be shared upstream.(a PKGBUILD file is roughly equivalent to debian/rules).

Also, would it be reasonable to just improve the makefiles to handle whatever's missing there for Debian packaging?

Of course that would be an option - adding a pkg-config file is relatively easy, the biggest annoyance is usually multiarch support. But expanding the Makefiles is - at least from my perspective - much more work than adding ~50 lines of Meson build definitions.

I was surprised by this. rdmd definitely needs to be packaged a lot more than, e.g., Dustmite.

Each package has a maintenance cost, and the D team in Debian consists of only two active people. Also, nothing is using rdmd yet, the DebianMed team (which is actually packaging undeaD/BioD/Sambamba) just encountered the first one with Sambamba, and replacing rdmd was easier than taking on the cost of maintaining dlang/tools - at least for now. This might change in future.

Because it's not distro-specific.

Understood. However, if a build system is only used in practice when building a package for one distribution, it's still effectively distro-specific :) If another distro tomorrow proposes adding a build specification for a different build system and argument that they can't use either Meson or dub/rdmd/make for reasons similar to your arguments above, we are back to the same dilemma. Granted, this is probably unlikely in this case, but I'm also interested in finding the correct solution here so that it could work as a precedent for future similar situations.
I hold the opinion that files specific to tools which are immediately useful to a single party should be maintained in a repository under that party's control. Though, of course, this is just my personal opinion and it's ultimately up to @dlang.
Since this is becoming political, pinging @andralex @WalterBright @MartinNowak to weigh in.

However, if a build system is only used in practice when building a package for one distribution, it's still effectively distro-specific

Since BioD is using Meson too, having it in undeaD would be kind of necessary to make their Meson builds work outside of Debian. Granted, technically Meson isn't required here but something installing a pkg-config file to the right place, but Meson is one way to achieve that.

If another distro tomorrow proposes adding a build specification for a different build system and argument that they can't use either Meson or dub/rdmd/make for reasons

Any distro shipping GNOME will have Meson, since many GNOME tools are switching to it - some developers even claimed that they will support Meson exclusively soon. I don't know any distro which doesn't have it yet.
DUB doesn't work for any distro, rdmd goes only half the way, Makefiles require more work.
If someone wants a cmake build file or extend the Makefile, do it and we can drop the Meson file. I really don't care as long as there is any one build system available which works well with distro packaging.
We can always patch stuff downstream, but especially stuff which is useful for many parties makes sense to submit back to upstream projects (like in this case).

Since BioD is using Meson too

OK, but I see that the Meson build file was also added there by yourself, so I think it wouldn't be fair to count BioD as an additional party using Meson, as they likely wouldn't have added one from their initiative. Here is the discussion for that change: https://github.com/biod/BioD/pull/26

Any distro shipping GNOME will have Meson, since many GNOME tools are switching to it

Good to know. Full disclosure, I went into this conversation biased by having never heard of it before today.

We can always patch stuff downstream,

Would you actually need to patch anything in this case, though? I understand that you would simply need to include and invoke meson.build from the distribution package's build script.

but especially stuff which is useful for many parties makes sense to submit back to upstream projects (like in this case).

I don't disagree, I just think it would be prudent for there to be evidence that the contribution is indeed immediately useful to multiple parties before accepting it into the source tree. I hope we can agree on that. I think the proper way forward is to keep this PR open until a second party will find the addition here immediately useful (but that's just my opinion).

OK, but I see that the Meson build file was also added there by yourself, so I think it wouldn't be fair to count BioD as an additional party using Meson, as they likely wouldn't have added one from their initiative.

Jup, but BioD initially only had a dub file which we can do nothing with at the moment, until dub is changed to work well for distros. So, in case of BioD, anyone who wants it in their distro will need to use the Meson file at time (I seriously tried to make dub work for packaging last year, and it only sort of worked with loads of hacks and ultimately writing Makefiles and Meson files for each project was by far the easier way).

Good to know. Full disclosure, I went into this conversation biased by having never heard of it before today.

I was also very skeptic, but after going to lunch with one of the Meson developers at the last GUADEC conference I was convinced (and at the time, this neatly solved the dub issues we had at Debian, and Meson upstream helped me a lot in adding support for the D language to it. So far, this is a great success :) )

I don't disagree, I just think it would be prudent for there to be evidence that the contribution is indeed immediately useful to multiple parties before accepting it into the source tree. I hope we can agree on that.

Classical henn-and-egg problem here ;-) I am not aware of other distros wanting to package undeaD (I originally asked Andreas who is doing the packaging at Debian to port BioD away from undeaD, but that is way more work than I expected and not feasible for us downstream at time - aspecially since it will break ABI and API, which is a no-go). But when it happens, they will find the Meson file helpful.
Btw, for me it's all a matter of how much effort it is to make stuff work for Debian. For GtkD for example, a pretty complete makefile existed already, so the easiest way to make that work for us was to just submit a few patches to make it follow the Debian FHS. Here, adding a Meson file was just simpler.

I am not aware of other distros wanting to package undeaD

I think any D package being packaged by two different distros using a Meson build would work, as then that would be the precedent that this PR could follow.

I think any D package being packaged by two different distros using a Meson build would work, as then that would be the precedent that this PR could follow.

At least appstream-generator is built using Meson in Arch (and its dependency mustache-d is as well): https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/appstream-generator
Fedora doesn't have it since the RPM backend for asgen isn't complete.
Granted, this is my own software ^^ (but it ships a working dub file too) The only other packaged D software I am aware of are Terminix and GtkD, which use Automake and rich Makefiles respectively (with Terminix having Meson too).

Another submission: https://github.com/dlang/undeaD/pull/33

As mentioned on biod/BioD#26, I think
it would be better to use wildcards here as undead doesn't get much love from a maintenance perspective.

Meson does nog allow for wild cards. It is also considered bad practice for reproducible build systems.

it would be awesome to check the Meson build automatically on Travis

I think it is done in #33.

I wonder who is still using unDead outside sambamba? Maybe I should just merge the code into our tree and be done with it. Not much of a point of having an unDead package in major distros if no one uses it.

I wonder who is still using unDead

https://github.com/search?q="import+undead"+language%3AD&type=Code

outside sambamba?

Never heard of that project before now.

Woops! I stand corrected. Code never dies, as they say. Very much unDead.
sambamba is used around the word in sequencing centers. 43K downloads on Bioconda. https://github.com/biod/sambamba

I think we can leave this out. BioD was the main driver for meson. See #33.

Jup - I have no interest in undeaD other than for making BioD work. Ideally, each project should just drop undeaD dependencies as soon as possible anyway.


CHANGELOGs appear to contain duplicated lines

At first glance, it looks like CHANGELOG.md files contain duplicate comments.
For example, below is a snippet from ockam_vault/CHANGELOG.md where it looks like lines newer releases are being copied from previous releases (e.g. Switch to arch agnostic integers for secret length).
## 0.67.0 - 2022-11-08

### Changed

- Switch to arch agnostic integers for secret length
- Codespell implementations/rust/
- Complete hkdf version update
- Updated dependencies

### Removed

- Remove bls support

## 0.66.0 - 2022-09-21

### Changed

- Switch to arch agnostic integers for secret length
- Updated dependencies

## 0.65.0 - 2022-09-09

### Changed

- Switch to arch agnostic integers for secret length
- Updated dependencies

This appears to happen in multiple CHANGELOG.md files, for example in ockam_command and ockam_core.

@neil2468 Thank you for reporting this.

Thanks @neil2468.
Our tags after ockam_v0.63.0 diverge from develop branch due to Mergify changing commit SHA after PRs are merged, this causes develop branch to assume our last release tag was ockam_v0.63.0  (running git describe --tags --abbrev=0).  I have added a workflow that updates commit SHA to that created by Mergify.


Fix call to the opencensus HTTPExecutorFactory

so it receives the bac…kend configurations.
Updated deps to use latest opencensus and lura version to include other bugfixes in the framework.

closes #278


Optimize redraw issue which happens in visual editor lg hook

In 'visual-designer/utils/hook.ts', there is a hook named useLgTemplate whose responsibility is to query lg content from lg template string, if it can't find a template, a new lg template will be created.
According to my profiling result, every time we clicking on visual editor, this hook will trigger redraw twice, seems not all redraw problems were solved in #1496 .
Obviously, a pure renderer shouldn't be coupled with this kind of behavior. We need to do some refactoring to make the lg querying behavior under control, make it on-demand instead of auto triggerred by a React hook.

In the hook file, even lg content not changed, useEffect will still trigger a state change.
We are actually triggering state changes inside the useEffect, it's obviously anti-pattern.
I want to make a small change: check if previousLgText === currentLgText, if they are equaled, don't setState.

Addressed in #2173 . Uses another solution by leveraging local data. Now it's fully resolved.


Updating owned collection only adds, never removes.

Is this intended behavior or am I not following the example properly? How can we delete entries from the collection?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d02e6748-42e0-000a-4945-42cd05a0b875
Version Independent ID: e3effbd0-07f2-423d-4032-1722e75adb37
Content: Owned Entity Types - EF Core
Content Source: entity-framework/core/modeling/owned-entities.md
Product: entity-framework
Technology: entity-framework-core
GitHub Login: @AndriySvyryd
Microsoft Alias: ansvyryd

@lp-ly Could you show the code you are using ti delete the entries?

I figured out what the problem was. In my situation, we queried with AsNoTracking. So without tracking you can only add entries then, correct?


Create "micro-batch" ingestion from external queue

Is your feature request related to a problem? Please describe.
Some queues charge by the message.  When one record is sent per queue message, the cost can add up for many small records.
Describe the solution you'd like
Support the ability to pack (and then later unpack) multiple records into a single queue message.
Supporting issues

https://github.com/Senzing/stream-producer/issues/39
https://github.com/Senzing/stream-loader/issues/84
https://github.com/Senzing/redoer/issues/47

stream-producer and stream-loader complete. stream-logger does not need to change. Just redoer remains.

stream-producer and stream-loader complete. stream-logger does not need to change. Just redoer remains.

For now, we are waiting until Senzing returns redo records as json, which is a commonly desired feature but there is no schedule for when that will be.
If there is a compelling reason to do it sooner, we will reasses.


Update rdf4j-model, rdf4j-query, ... to 4.3.1

About this PR
📦 Updates

org.eclipse.rdf4j:rdf4j-model
org.eclipse.rdf4j:rdf4j-query
org.eclipse.rdf4j:rdf4j-queryalgebra-evaluation
org.eclipse.rdf4j:rdf4j-queryalgebra-model
org.eclipse.rdf4j:rdf4j-queryparser-sparql
org.eclipse.rdf4j:rdf4j-rio-rdfxml
org.eclipse.rdf4j:rdf4j-storage

from 3.7.7 to 4.3.1 ⚠
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.eclipse.rdf4j" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.eclipse.rdf4j" }
}]

labels: library-update, early-semver-major, semver-spec-major, commit-count:1

Superseded by #88.


feat(server): should print correct urls by html entry

Summary
entry (single): index

entry (single): foo

entry(multiple): foo、bar

Related Issue
fix: #448

Checklist

[ ] I have added changeset via pnpm run change.
[ ] I have updated the documentation.
[ ] I have added tests to cover my changes.

👍🏻 Good job


#1495 Enable parallel tests.

A container can be shared among different tests classes via container defined in a base class for parallel tests.
I used synchronized because right now the execution is single threaded, booting up one container after other. In the future I would like to change it to run in threads.
Related Issue:
https://github.com/testcontainers/testcontainers-java/issues/1495

See https://github.com/testcontainers/testcontainers-java/issues/1495#issuecomment-770024127

See https://github.com/testcontainers/testcontainers-java/issues/1495#issuecomment-770024127

@marciovmartins if you don't mind, let's keep the PR open (and we will get to it soon), just so that jupiter's parallel mode would work, too (without requiring code changes) :)

@marciovmartins if you don't mind, let's keep the PR open (and we will get to it soon), just so that jupiter's parallel mode would work, too (without requiring code changes) :)

Any ETA on this one?

Ping

@marciovmartins, @bsideup, any ETA, please?

@pavlo-sv I don't think this will ever happen, see the link to the the issue request and the discussion there.
Part of my test was copied here:
https://github.com/testcontainers/testcontainers-java/blob/main/modules/junit-jupiter/src/test/java/org/testcontainers/junit/jupiter/ParallelExecutionTests.java


Indexer API updates

Can one of the admins verify this patch?

Hi @chaosrealm, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (eugenesh). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;


fix NullPointerException when address already in use

What is the purpose of the change
The error message is not clear if port 20880 is already in use
Brief changelog
To avoid NullPointerException when throw the RemotingException
Verifying this change
Checklist

[Y] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[Y] Each commit in the pull request should have a meaningful subject line and body.
[Y] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[Y] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[Y] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[Y] Add some description to dubbo-website project if you are requesting to add a feature.
[Y] GitHub Actions works fine on your own branch.
[Y] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #10785 (fbd4130) into 3.1 (e95c4b5) will decrease coverage by 1.22%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##                3.1   #10785      +/-   ##
============================================
- Coverage     65.74%   64.52%   -1.23%
- Complexity      416      470      +54
============================================
  Files          1342     1336       -6
  Lines         59038    56955    -2083
  Branches       8948     8399     -549
============================================
- Hits          38813    36748    -2065
- Misses        16173    16255      +82
+ Partials       4052     3952     -100

Impacted Files
Coverage Δ

...pache/dubbo/remoting/transport/AbstractServer.java
61.03% <0.00%> (-3.90%)
:arrow_down:

...luster/router/script/ScriptStateRouterFactory.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...zookeeper/curator/CuratorZookeeperTransporter.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...pc/cluster/router/file/FileStateRouterFactory.java
0.00% <0.00%> (-80.96%)
:arrow_down:

...o/rpc/cluster/router/script/ScriptStateRouter.java
0.00% <0.00%> (-67.31%)
:arrow_down:

...mmon/serialize/fastjson2/FastJson2ObjectInput.java
0.00% <0.00%> (-62.50%)
:arrow_down:

...mon/serialize/fastjson2/FastJson2ObjectOutput.java
0.00% <0.00%> (-56.25%)
:arrow_down:

...ting/zookeeper/curator/CuratorZookeeperClient.java
15.38% <0.00%> (-55.99%)
:arrow_down:

...dubbo/remoting/zookeeper/ZookeeperTransporter.java
50.00% <0.00%> (-33.34%)
:arrow_down:

...o/rpc/protocol/tri/transport/GracefulShutdown.java
51.85% <0.00%> (-29.63%)
:arrow_down:

... and 120 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


No lib folder in node_modules

refine-firebase folder in node_modules comes without the lib folder when execute "npm i refine-firebase".
For using this module, I needed clone this project, build it and copy the lib folder to my refine project.

Can you try again. I Fixes this issue with a new version

Now, it's ok.
Thanks.


Updates for 0.7

This isn't ready yet, but I wanted to see what you thought @ethul
Changes involved: removal of psc, renamed pscMake to psc, added src option for accepting source file globs rather than the previous stream of files from gulp.
Since we don't have a stream anymore, I wrapped the task in a Promise instead, as this way you can still use it in gulp tasks without having to manually pipe callbacks in with the task definition. This part in particular I wonder if you have any thoughts on - maybe there's a better way? Also I just used promise from npm for this, but q, bluebird, etc. would work too, if you have a preference.
Still to do: add a task for pscBundle, update dotPsci and pscDocs (if needed), remove a bunch of now uneeded stream-related stuff.

Thanks for kick-starting these updates @garyb. I think they look good.
I have some parallel changes (nothing major), but I can merge them in after you're ready with this PR.
Regarding using promises, I could really go either way. I think either a callback-based psc entry function or a promise-based one would work. Both are easy to use through gulp. If you keep the promise approach, the promise module looks like a good choice to me.
One question I had was about the src option for accepting globs. From what I gather, the haskell System.FilePath.Glob and the javascript glob module (as just one example of a glob module we may need to use) have differing syntax for globbing.
This doesn't pose an issue for psc, but if we want to generate a .psci file, I believe we'll need to ensure that what we are able to glob with javascript will be the same as what will end up being globbed by the purescript compiler. Therefore, I was wondering if we should only allow limited glob capabilities (by parsing the user's glob string and validating it). But maybe this isn't really an issue. I am curious on your thoughts.

Ah, that's an excellent point with the globbing syntax - I suppose we probably should validate the globs and at least raise a warning if it looks like the pattern is unsuitable. Perhaps for now we just make it work though, and then refine later. I suspect most people won't be using anything more advanced than the bower_components/purescript-*/**/*.purs, type glob anyway for PureScript projects.

Ok, this is mostly ready now, I've ham-fisted my way through most of the changes, but there's some things I couldn't quite figure out how to do:

pscBundle is done now as a promisified task and has an output option, but ideally I'd like to be able to use it as a stream so we can pipe it to a file, or another process, or whatever as with the old psc task.
for dotPsci I've made an options parser so we pass it src and ffi options to include both :m and :f (foreign) commands in the generated file, but I've not touched the task as again I'm not really sure what I'm doing when it comes to producing streams.

Would you mind having a look when you get a minute? Hopefully it'll be a quick change for someone who knows what they're doing :smile:

Awesome! Thank you for the updates. I will take a look at the streaming.
By the way, what do you think of renaming dotPsci to just psci?

Sounds good to me :+1:

I had the version set as 0.5.0-rc.2 in here so we'll need to update that before releasing.

Will do. Thanks for the heads up.


Linting on Jupyter Notebook fails after reordering cells

Hello, today I activated Ruff for Jupyter Notebooks and noticed some strange behavior I didn't see with normal Python files:
After reordering the cells of a notebook, the editor window shows false-positives from Ruff linting.
MWE
pyproject.toml
[tool.ruff]
extend-include = [
    "*.ipynb",
]

ruff.ipynb (with --- denoting a new cell)
import random
---
f = random.random()
---
g = random.random()

After moving the third cell with g = ... to the second position, Ruff reports F401 on import random.
Environment
Operating System Windows_NT x64 10.0.19045
VS Code 1.91.1 (commit f1e16e1e6214d7c44d078b1f0607b2388f29d729)
Ruff extension v2024.36.0

If I can help in narrowing the problem further down, please let me know.

Thanks but I've found out the root cause of this bug.
The reason this is occurring is because we model NotebookCell differently than the LSP spec internally but the change request is handled as per the spec. This means there's a mismatch in the expectations on how certain changes are requested to the server.
The difference is that we store the TextDocument inside the NotebookCell itself while it should be stored elsewhere and NotebookCell would just act as a pointer to the text document corresponding the cell.
So, what happens in this case where the cells are moved but the content remains the same. VS Code sends this request as just moving the URIs and doesn't provide any content.
{
    "notebookDocument": {
        "version": 1,
        "uri": "file:///Users/dhruv/playground/ruff/notebooks/issue.ipynb"
    },
    "change": {
        "cells": {
            "structure": {
                "array": {
                    "start": 1,
                    "deleteCount": 2,
                    "cells": [
                        {
                            "kind": 2,
                            "document": "vscode-notebook-cell:/Users/dhruv/playground/ruff/notebooks/issue.ipynb#W2sZmlsZQ%3D%3D",
                            "metadata": {
                                "metadata": {}
                            }
                        },
                        {
                            "kind": 2,
                            "document": "vscode-notebook-cell:/Users/dhruv/playground/ruff/notebooks/issue.ipynb#W1sZmlsZQ%3D%3D",
                            "metadata": {
                                "metadata": {}
                            }
                        }
                    ]
                },
                "didOpen": [],
                "didClose": []
            }
        }
    }
}

This goes back to https://github.com/astral-sh/ruff/pull/11864#discussion_r1639145836 as this explains why VS Code sends a request to close the text document corresponding to a notebook cell.


OverFlowed Bright problem

When i use this package in Row and write some words  code is giving an error overflowed.How to solve this problem?

Wrap Bubble by Flexible widget


Parse query string params to single values (not lists) in get_authorize_url method

A fix for issue #8

My bad... I'll fix the test.

Don't worry about it, I think @ej2 already has a fix in the auth_url_fix branch. Sorry for the non-communication.

Fix has been merged into master and deployed to PyPI.


fix(quantic): hide facet search when there are fewer values than max

@lbergeron your comment made me realize we should be using the flag returned by the API for whether there are more values available. Same as with the show-more button. Made the change 👍