Add Dexter-server Swagger documentation

Create dexter-server specification with Swagger

Look great! :)
I have some general comments, though:

please rename folder "dist" into "swagger". Current name is a little confusing
"dist" contains a lot of 3rd party stuff (images,js,html). I would suggest to to keep only what is necessary to build swagger docs by user and provide instruction in README.md.

Please add short notice to README.md, regarding swagger, including how to run it and on what port it is available.


Issue setting up sensors (no gas Mode range on pure EV)

First of all, I just wanted to say a massive thank you for taking the time to put this together. I was really hoping someone would, and really appreciate it.
When I installed it, I got an exception setting up the sensors:
2021-04-10 17:38:54 INFO (MainThread) [homeassistant.components.binary_sensor] Setting up binary_sensor.kia_uvo
2021-04-10 17:38:54 INFO (MainThread) [homeassistant.components.device_tracker] Setting up device_tracker.kia_uvo
2021-04-10 17:38:54 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.kia_uvo
2021-04-10 17:38:54 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new binary_sensor.kia_uvo entity: binary_sensor.niro_ev_19_hood
2021-04-10 17:38:54 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new binary_sensor.kia_uvo entity: binary_sensor.niro_ev_19_trunk
2021-04-10 17:38:54 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new binary_sensor.kia_uvo entity: binary_sensor.niro_ev_19_door_front_left
2021-04-10 17:38:54 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new binary_sensor.kia_uvo entity: binary_sensor.niro_ev_19_door_front_right
2021-04-10 17:38:54 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new binary_sensor.kia_uvo entity: binary_sensor.niro_ev_19_door_rear_left
2021-04-10 17:38:54 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new binary_sensor.kia_uvo entity: binary_sensor.niro_ev_19_door_rear_right
2021-04-10 17:38:54 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new binary_sensor.kia_uvo entity: binary_sensor.niro_ev_19_door_lock
2021-04-10 17:38:54 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new binary_sensor.kia_uvo entity: binary_sensor.niro_ev_19_engine
2021-04-10 17:38:54 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new binary_sensor.kia_uvo entity: binary_sensor.niro_ev_19_data
2021-04-10 17:38:54 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new device_tracker.kia_uvo entity: device_tracker.niro_ev_19_location
2021-04-10 17:38:54 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up kia_uvo platform for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 200, in _async_setup_platform
    await asyncio.shield(task)
  File "/config/custom_components/kia_uvo/sensor.py", line 16, in async_setup_entry
    ("fuelDrivingDistance", "Range by Fuel", vehicle.vehicle_data["vehicleStatus"]["evStatus"]["drvDistance"][0]["rangeByFuel"]["gasModeRange"]["value"], "km", "mdi:road-variant", None),
KeyError: 'gasModeRange'

Our Kia is an eNiro 4, so pure electric, so I'm not surprised by this. I guess it just needs handling.
When I look at binary_sensor.niro_ev_19_data the data seems to be all there as attributes, so I guess it is just the creation of the sensors, with a way to handle not having gasModeRange for pure EVs
  evStatus:
    batteryCharge: false
    batteryStatus: 47
    batteryPlugin: 0
    remainTime2:
      etc1:
        value: 41
        unit: 1
      etc2:
        value: 1180
        unit: 1
      etc3:
        value: 400
        unit: 1
      atc:
        value: 380
        unit: 1
    drvDistance:
      - rangeByFuel:
          evModeRange:
            value: 123
            unit: 3
          totalAvailableRange:
            value: 123
            unit: 3
        type: 2

thanks for reaching out, I own a Kia Niro Phev and my car has EV range and gas range. Apparently, you own an Kira Niro EV so you dont have gasModeRange attribute, Let me fix it, i will update here soon

can you please retry? It should be fixed with latest version

That worked great. Thank you!

Welcome


block gasLimit logic fixed

Fixed issue with the block gas limit enforcing

This leaves open an attack where a staker could force a transaction to run out of gas by filling the block with other gas consuming transactions until the block gas limit is nearly exceeded, and then adding the transaction they wish to make run out of gas. Some though is required to mitigate this attack vector

Rejecting this for now, to properly make this work would require changing to cpp-eth to cause execution to stop once the block gas limit is reached, without triggering an exception (but rather something else so we can determine it ran out of block gas, rather than transaction gas). So, instead we will enforce block gas limit at consensus level and make the staker smart enough to not mine contracts that might exceed the block gas limit, and if they do mine the contract they need to remove it from the block as it would be an invalid block otherwise


[ISSUE #3585] [Part J] Use MappedByteBuffer instead of FileChannel to …

Make sure set the target branch to develop
What is the purpose of the change
speed up reput performance (relative to consumer tps) .
Brief changelog
Use MappedByteBuffer instead of FileChannel to write consume queue and slave commitlog.
Verifying this change
This commit improve reput performance and speed up consume qps greatly. In our test, produce about 200,000 tps.
72 queue consume qps: from about 70,000 to 200,000
600 queue consume qps: from about 70,000 to 110,000
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed 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.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) 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 integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Coverage increased (+0.04%) to 56.186% when pulling 122a69bb51d7485b6ae8d2c343ca8ae422736bd3 on areyouok:492_PartJ into ecb061ae425f76ad28a597293b98f374ceba14ec on apache:develop.

Codecov Report

Merging #3657 (122a69b) into develop (ecb061a) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

@@              Coverage Diff              @@
##             develop    #3657      +/-   ##
=============================================
- Coverage      49.69%   49.67%   -0.02%
+ Complexity      4725     4723       -2
=============================================
  Files            555      555
  Lines          36798    36800       +2
  Branches        4853     4853
=============================================
- Hits           18286    18281       -5
- Misses         16214    16220       +6
- Partials        2298     2299       +1

Impacted Files
Coverage Δ

...ain/java/org/apache/rocketmq/store/MappedFile.java
50.18% <100.00%> (-0.01%)
:arrow_down:

...in/java/org/apache/rocketmq/test/util/MQAdmin.java
38.88% <0.00%> (-5.56%)
:arrow_down:

...apache/rocketmq/remoting/netty/ResponseFuture.java
85.00% <0.00%> (-5.00%)
:arrow_down:

...sumer/rebalance/AllocateMessageQueueAveragely.java
56.52% <0.00%> (-4.35%)
:arrow_down:

...rocketmq/remoting/netty/NettyRemotingAbstract.java
46.88% <0.00%> (-4.03%)
:arrow_down:

...he/rocketmq/client/trace/AsyncTraceDispatcher.java
77.22% <0.00%> (-1.00%)
:arrow_down:

.../rocketmq/broker/filter/ConsumerFilterManager.java
72.19% <0.00%> (-0.90%)
:arrow_down:

...a/org/apache/rocketmq/store/StoreStatsService.java
29.50% <0.00%> (-0.66%)
:arrow_down:

...org/apache/rocketmq/store/DefaultMessageStore.java
56.04% <0.00%> (-0.20%)
:arrow_down:

... and 10 more

Continue to review full report at Codecov.

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

before:

after:

Actually, mmap is better than fileChannel in small size message case. In large scale size message, fileChannel is more better.
There could be an option to switch mmap/fileChannel.
See https://www.jianshu.com/p/d0b4ac90dbcb

As another effect, we found after upgrade to 4.9.4, mmap avoid many swap usage rather than older version with fileChannel.
See https://stackoverflow.com/questions/49996217/filechannel-vs-mappedbytebuffer-in-random-access

As another effect, we found after upgrade to 4.9.4, mmap avoid many swap usage rather than older version with fileChannel.
See https://stackoverflow.com/questions/49996217/filechannel-vs-mappedbytebuffer-in-random-access


remove yaml support + fix config flow options

Removes the previously deprecated yaml support BREAKING CHANGE, therefore I suggest version v3
Fixes some bug with the config flow:

Update entities if we change the setting via Option Handler
Use values from Options Handler
Add "already_configured" error to translations

Sort all json files

@dckiller51 I would suggest, that we release v3 together with #75, after I have finish it. Takes me probably another week

I just did the tests. It works well. I'll just have to make an update for the FR traction.

@edenhaus
Hello, have you finalized your update?

@dckiller51 I still need to convert the body score to the new format in #75 but than I'm ready. Sorry but I had this month real life problems and they have priority, but I hope I can finish it next week. I will merge this PR as I need it in #75, but don't release a version yet as we should include #75 in the new version

No problem you are right personal life is most important. Good luck in your difficult times.


AltSchool Logo in light mode

Good day,
I kinda like the idea of AltSchool logo being in the Readme.md file, but PR #276 which was merged sort of deleted the image from the repo and right now the AltSchool logo does not display in Light Mode while PR #239 was a fix to properly display different AltSchool logo in either Dark or Light Mode

I will like to fix this. let me check it out

@Succynice what do you think?

cc @Psalmzee @oseunabiola

Has this issue been fixed? @Omafovbe if yes. you can close the issue too. Will you be interested in helping with the admin work here. The PR is growing so fast.

Sure...will get on it now.
On Thu, Aug 11, 2022 at 11:36 AM Olúwásetèmi @.***>
wrote:

Has this issue been fixed? @Omafovbe https://github.com/Omafovbe if
yes. you can close the issue too. Will you be interested in helping with
the admin work here. The PR is growing so fast.
—
Reply to this email directly, view it on GitHub
https://github.com/Oluwasetemi/altschool-opensource-names/issues/310#issuecomment-1211815654,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQDL6AKPL7L4VGYMNKDRBV3VYTJTRANCNFSM56GPUGAQ
.
You are receiving this because you were mentioned.

@Oluwasetemi it has not been fixed. There need to exist two image files on the repo one to display for dark mode and another to display in light mode. right now only one image file exist which displays on dark mode. The image file AltSchool.svg shouldn't have been deleted.
Lastly, I accept the offer to help with the admin work.

Thanks its confirmed

Yes it has. and i would be closing the issue. Thanks
On Thu, Aug 11, 2022 at 2:28 PM Success Chikezie @.***>
wrote:

@Omafovbe https://github.com/Omafovbe thanks for this observation, my
last PR #338
https://github.com/Oluwasetemi/altschool-opensource-names/pull/338 has
done justice to this, please confirm
—
Reply to this email directly, view it on GitHub
https://github.com/Oluwasetemi/altschool-opensource-names/issues/310#issuecomment-1211989999,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEXP2H3YKVZWS24BKDPGTQTVYT5XVANCNFSM56GPUGAQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


OpenRailRouting Customizations

This PR does the following:

Sets a disclaimer in the README about the fork
Comments out the frontend graphhopper UI invocation
~Attempts to make the project readonly with respect to the filesystem~ This didn't work
Modifies network binding from localhost to <IP_ADDRESS>

I also got rid of the previous tags (hopefully) so that we can start fresh

Are you manually releasing tags? when making changes in this repo?

As discussed in slack, I'm modifying my dockerfile locally to hit the feature branch in this repo and pushing that to ECR


long subject + body results in an error (mail)

Greetings!
I encouter a weird problem.
When my subject + body reach a certain length, the program breaks with following error: Uncaught SoapFault exception: [Client] looks like we got no XML document
This wouldn't be a big problem but it occurs already at 168 characters.
What I've tested so far:
Subject 6 chars + body 161 chars -> Mail is correct
Subject 6 chars + body 162 chars -> Error
Subject 5 chars + body 162 chars -> Mail is correct
Mails and events are working fine but just as said, errors occur when there are too many characters.
Here is my code:
$ews = new ExchangeWebServices($server, $username, $password, ExchangeWebServices::VERSION_2010_SP2);
$msg = new EWSType_MessageType();

$fromAddress = new EWSType_EmailAddressType();
$fromAddress->EmailAddress =<EMAIL_ADDRESS>$fromAddress->Name = 'some name';
$msg->From = new EWSType_SingleRecipientType();
$msg->From->Mailbox = $fromAddress;

$msg->Subject = "123456";

$msg->Body = new EWSType_BodyType();
$msg->Body->BodyType = 'HTML';
$msg->Body->_ = "Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At ve";

$msgRequest = new EWSType_CreateItemType();
$msgRequest->Items = new EWSType_NonEmptyArrayOfAllItemsType();
$msgRequest->MessageDisposition = 'SendAndSaveCopy';
$msgRequest->MessageDispositionSpecified = true;

$msg->ToRecipients = new EWSType_ArrayOfRecipientsType();
$toAddress = new EWSType_EmailAddressType();
$toAddress->Name = "some name";
$toAddress->EmailAddress =<EMAIL_ADDRESS>$msg->ToRecipients->Mailbox = $toAddress;
$msgRequest->Items->Message = $msg;
$response = $ews->CreateItem($msgRequest);

Server is Exchange 2013, tried VERSION_2010_SP1 also, but didn't help.
Setting the type to Text
$msg->Body->BodyType = 'Text';

did no change either.
Tried with these Environments:
Apache 2.2.25 + PHP 5.2.17
and
Apache 2.4.12 + PHP 5.5.25
Both fail identical.
Any suggestions?
Edit:::I did further investigations
Sending the long body as an event is successful.
I tried the PHP mail() function via SMTP and received the mail as given.
So I assume sending a message with a long body via this API is the problem - maybe programming mistake?
Does anyone have experience with long message bodies via this API?

I have experienced the same problem, looking for any suggestion.

I've added a new message/create example that uses a much longer body and subject and the message is created just fine. There have been a number of changes to this library since this was reported, so it's possible that updating to the latest commit may resolve your issue.


Mnist data is changed

The network uses data[0].expected, which is undefined in the mnist set.
Maybe check if .expected is undefined and use .output?

That's actually how it used to work, before I changed it to simplify it. I've added it back now, as part of v3.4.1.


Injection issue in rails 7 & ruby 3.1

We have more than 20 rails app using rails 6 & below and ruby 2.7 & below, there are implemented service pattern using dry injection, it is broken on rails 7 & ruby 3.1
I'm getting an error looks like
Started POST "/api/v1/posts/search.json" for ::1 at 2022-02-16 00:26:43 +0000

ArgumentError (wrong number of arguments (given 1, expected 0)):

actionpack (<IP_ADDRESS>) lib/action_controller/metal.rb:150:in `initialize'
actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/url_for.rb:108:in `initialize'
dry-auto_inject (0.9.0) lib/dry/auto_inject/strategies/kwargs.rb:71:in `block (2 levels) in define_initialize_with_splat'
dry-auto_inject (0.9.0) lib/dry/auto_inject/strategies/kwargs.rb:22:in `new'
dry-auto_inject (0.9.0) lib/dry/auto_inject/strategies/kwargs.rb:22:in `block (2 levels) in define_new'
actionpack (<IP_ADDRESS>) lib/action_controller/metal.rb:251:in `dispatch'
actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/route_set.rb:49:in `dispatch'
actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/route_set.rb:32:in `serve'
actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:50:in `block in serve'
actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:32:in `each'
actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:32:in `serve'
actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/route_set.rb:850:in `call'
rack (2.2.3) lib/rack/etag.rb:27:in `call'
rack (2.2.3) lib/rack/conditional_get.rb:40:in `call'
rack (2.2.3) lib/rack/head.rb:12:in `call'
actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/callbacks.rb:27:in `block in call'
activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:99:in `run_callbacks'
actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/callbacks.rb:26:in `call'
actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/executor.rb:14:in `call'
actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/actionable_exceptions.rb:17:in `call'
actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/debug_exceptions.rb:28:in `call'
actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/show_exceptions.rb:26:in `call'
railties (<IP_ADDRESS>) lib/rails/rack/logger.rb:36:in `call_app'
railties (<IP_ADDRESS>) lib/rails/rack/logger.rb:25:in `block in call'
activesupport (<IP_ADDRESS>) lib/active_support/tagged_logging.rb:99:in `block in tagged'
activesupport (<IP_ADDRESS>) lib/active_support/tagged_logging.rb:37:in `tagged'
activesupport (<IP_ADDRESS>) lib/active_support/tagged_logging.rb:99:in `tagged'
railties (<IP_ADDRESS>) lib/rails/rack/logger.rb:25:in `call'
actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/remote_ip.rb:93:in `call'
actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/request_id.rb:26:in `call'
rack (2.2.3) lib/rack/runtime.rb:22:in `call'
activesupport (<IP_ADDRESS>) lib/active_support/cache/strategy/local_cache_middleware.rb:29:in `call'
actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/server_timing.rb:20:in `call'
actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/executor.rb:14:in `call'
actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/static.rb:23:in `call'
rack (2.2.3) lib/rack/sendfile.rb:110:in `call'
actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/host_authorization.rb:137:in `call'
railties (<IP_ADDRESS>) lib/rails/engine.rb:530:in `call'
puma (5.6.2) lib/puma/configuration.rb:252:in `call'
puma (5.6.2) lib/puma/request.rb:77:in `block in handle_request'
puma (5.6.2) lib/puma/thread_pool.rb:340:in `with_force_shutdown'
puma (5.6.2) lib/puma/request.rb:76:in `handle_request'
puma (5.6.2) lib/puma/server.rb:441:in `process_client'
puma (5.6.2) lib/puma/thread_pool.rb:147:in `block in spawn_thread'

To Reproduce

create a new app using rails 7 with api mode
create a service with a single method so we have this structure under app directory

app/
  controllers/
    api/
      v1/
  ...
  ...
  services/
    v1/

module V1
    class PostService
        def search(keyword)
             "OK"
        end
    end
end

create a container class named di_container.rb on lib/marka/ directory and register and initialize the PostService class

require 'dry-container'
require 'dry-auto_inject'

module Marka
    class DiContainer
        extend Dry::Container::Mixin

        register :v1_post_service do
            V1::PostService.new
        end
    end
    INJECT = Dry::AutoInject(Marka::DiContainer)
end

create a new controller called posts_controller under app/controllers/api/v1/ directory, and try to inject the method which registered on Marka module

require 'marka/di_container'
module Api
  module V1
    class PostsController < ApplicationController
      include Marka::INJECT[:v1_post_service]

      def search
         render json: { status: "OK" }
      end
    end
  end

Expected behavior
Upgrade our apps to rails 7 using the same pattern.
My environment

Affects my production application: YES due to development issue
Ruby version: 3.1
Rails <IP_ADDRESS>
OS: MacOS Mojave 10.14.6
dry-auto_inject (0.9.0)
dry-container (0.9.0)

stakeoverflow question :
https://stackoverflow.com/q/71131422/2858044

This was moved from dry-auto_inject because we could come up with a nice integration with the controller API. Marking it as help-wanted as I don't have time (for now at least) to work on this.

I thank you @solnic for your response and help to moved this issue.
I thought dry-auto-_inject is supported the ruby ecosystem, including rails. I have use that (starting rails 4 & ruby 2.3) which is since 5 years ago and stable for production until now with more than 20 rails apps using rails 6 and below, and still thinking upgrade them early to rails 7.
I need to find another way to make it work without big changes, for the moment I try to use dry-rails, and I'm not sure about this strategy
Add a path app/services to container
# config/initializers/marka.rb
Dry::Rails.container do
    config.component_dirs.add "app/services"
end

and in controller I can call looks like
MyApp::Container['v1.post_service'].search(params[:keyword])

What do you think about this?

I thought dry-auto-_inject is supported the ruby ecosystem, including rails.

I should clarify - dry-auto_inject works with Rails but you assume you can use it with any class, which is not the case because the purpose of dry-auto_inject is to define a constructor method that will receive dependencies that are automatically resolved from the configured container. Because of this, it is not advices to include injection modules in classes that you don't own because it may break them.
We should definitely explain this in the docs 🙂

MyApp::Container['v1.post_service'].search(params[:keyword])
What do you think about this?

Actually, dry-rails gives you a resolve helper in controllers, so this can become resolve('v1.post_service').search(params[:keyword]). You could also provide a temporary solution while you're in the process of migrating to dry-rails by simply defining method_missing in your application controller, something like this should work:
def method_missing(name, *args)
  if container.key?("v1.#{name}")
    resolve("v1.#{name}")
  else
    super
  end
end

This is obviously a hack but it should help with the transition 🙂

On our project we updated dry-rb to the latest version and faced the same issue, so we decided to build our own injection strategies for controllers. Here it is:
# frozen_string_literal: true

require "dry/auto_inject/dependency_map"

module Dry
  module AutoInject
    class Strategies
      class Resolve < Module
        InstanceMethods = Class.new(Module)

        attr_reader :container
        attr_reader :dependency_map
        attr_reader :instance_mod

        def initialize(container, *dependency_names)
          super()
          @container = container
          @dependency_map = DependencyMap.new(*dependency_names)
          @instance_mod = InstanceMethods.new
        end

        # @api private
        def included(klass)
          define_resolvers
          klass.send(:include, instance_mod)
          super
        end

        private

        def define_resolvers
          instance_mod.class_exec(container, dependency_map) do |container, dependency_map|
            dependency_map.to_h.each do |name, key|
              define_method name do
                container[key]
              end
            end
          end
        end
      end

      register :resolve, Resolve
    end
  end
end

and then in controllers we do:
include YourApp::Import.resolve[
  'your.operations.name',
]

Hi @solnic ! I'm also struggling with this issue after upgrading from dry-rails v0.2 to the latest. I don't think that it's a Rails problem because I'm still at Rails v<IP_ADDRESS>. I'm also tried to reproduce the bug in test for dry-rails and it's failed. Like this:
class ApiUsersController < ActionController::API
  include Dummy::Deps[
    mailer: "mailer"
  ]
  ...
end

 ArgumentError:
       wrong number of arguments (given 1, expected 0)
     # ./spec/requests/api_users_spec.rb:16:in `block (4 levels) in <top (required)>'

I think there is something wrong with dry-auto_inject but I don't know yet what exactly. Maybe you can give some advice?
Thanks!

I'm not sure that this is a smarter one but it fixes the problem https://github.com/k0va1/dry-rails/commit/767154a3e8e320b54a6725783afd7df5aa3e0acd

Hi @solnic I just informed from my colleague, it's weird the problem is solved when I use action controller base instead of using the api mode. meanwhile the api mode is a lightweight version, which is exclude some modules from base.

My app worked without problems using Rails 7.0 and Ruby 3.3. Problem appeared after upgrading to Rails 7.1.
Solution proposed by @k0va1 helped. At least for now. Can we get it merged?

Same problem with @oskargargas after upgrading to Rails 7.1

@charlieoliver I'd love it if someone could submit a PR to address this.

@charlieoliver I'd love it if someone could submit a PR to address this.

Not in my skill set but I hope that putting the ask out there may spark something! Thank you for responding!


Offcanvas and Modal open and close immediately on some touch devices

Prerequisites

[X] I have searched for duplicate or closed issues
[X] I have validated any HTML to avoid common problems
[X] I have read the contributing guidelines

Describe the issue
If an offcanvas (or modal) is not triggered via a button with data-bs-toggle, but is opened "manually" via a pointerup or pointerdown event, it closes again immediately on some touch devices because the backdrop receives an additional event.
Reduced test cases
You can see this clearly in this fiddle:
https://jsfiddle.net/andreas_walter/cpoL102a/
(To test with e.g. microsoft surface touchscreen or android tablet)
What operating system(s) are you seeing the problem on?
Windows, Android
What browser(s) are you seeing the problem on?
Chrome, Firefox, Microsoft Edge, Opera
What version of Bootstrap are you using?
v5.3.3

A "hacky" method to get around this is:
const offcanvas = new bootstrap.Offcanvas('#offcanvas-ondown');
let save = offcanvas._config.backdrop;
offcanvas._config.backdrop = 'static';
offcanvas.show();
window.setTimeout(function () {
    offcanvas._config.backdrop = save;
}, 500);

It seems to be related to #39780


Publish Encrypt and Sign public key

I would like to be able to extract the public key for a signature and encryption operation so that I can exchange it with other parties. Unfortunately the tink classes are not serialisable. The initail idea would be to extract just the public key as a json object so that it can be sent over a REST call to another party.
I could write it to a file, but that seems an unnecessary step and overly complex.

For exporting public keys one can use KeysetHandle.writeNoSecret(writer), where writer could be a JsonKeysetWriter, that writes an output stream (that can be in-memory).  The receiving party would then use KeysetHandle.readNoSecret(reader) with a JsonKeysetReader.  This flow does serialize the keysets though, and currently we don't offer API that provides json objects.
For persisting secret keys one can use a CleartextKeysetHandle.
Please reopen if this doesn't solve the problem.


function for remove all markers

Please, add function for remove all markers on the canvas layer.
Thank you!

something like: clearLayers()

Added clearLayers() method.
It removes all layers and event listeners from the canvas layer


Multilingual support

Some customers in Japan request us to translate this page into Japanese. I want to contribute to create Japanese pages. Any plan to support non-English languages in this site ?
I don't know much about docusaurus, but it seems to have multi-language support. i18n - Introduction

Thanks for the feedback. Will investigate the "internationalization" feature from docusaurus.

@konabuta - we have added the skeleton for internationalization. You should be able to create japanese pages of the website under the i18n/ directory.
Please see this tutorial for how to do so: https://docusaurus.io/docs/2.0.0-alpha.71/i18n/tutorial
(As you already found!)
Thanks again!

@aminsaied Could you check this comment ? Thanks.
https://github.com/Azure/azureml-cheatsheets/issues/66#issuecomment-851012309

Japanese translation markdown is merged. Thanks.


fix: Add missing inputs for HuggingFace model component and include pytest

Added missing inputs to the HuggingFace model component to enhance functionality.
Implemented pytest to ensure that the inputs are correctly handled and validated.

closes #4182


Add Projects

Do and add starred exercises from "Stacks and Queues - Exercise"

Do and add remaining exercises from "Multidimensional Arrays - Exercise"


Possible semantic versioning order issue at double-digits

Hi, we seem to have encountered an issue with migration ordering in our project.
We've got database migrations from V1_1_0 up to at least V1_13_0 in our project, but we've just noticed that in the database itself, the migrations have been ordered differently to what we were expecting.
Expected
We were expecting that 1.9.0 -> 1.10.0 -> 1.11.0, based on https://semver.org/#spec-item-2:

A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

Actual
However, we're actually seeing: 1.1.0 -> 1.10.0 -> 1.11.0 -> 1.2.0 -> ....

Is this expected behaviour?

@harry-graham it is not.

@marianozunino thanks for looking into this so quickly! 🙌🏼
If we completely wipe the database and start fresh with 0 migrations, and run all migrations at once, then the migrations get run in the correct order.
However, if we try to run the migrations command again, even if there aren't any new migrations to run, then the command crashes.
In our example:

We have migrations V1_0_0 up to V1_13_0
On the first attempt, they all get run in the correct order as desired
On any future attempts, the migrations command attempts to first execute migration V1_2_0 again as the next migration to run

This crashes because the node already exists in the database for that migration

It might be that it sees "V1_13_0" as the latest applied version, but then still sees "V1_2_0" as being a candidate migration?

@harry-graham can you test this branch before I merge it?
I found the bug bug that you described, but I want to make sure that everything else works just fine. The info command was miss sorting the migrations as well.

Clone the repo, checkout the branch and execute this command
npm i; npm run build; node dist/main.js

@marianozunino thanks for the instructions, that worked 👍🏼
I've tested with the new branch, and it resolves the previous issue we were seeing, thanks! 🙌🏼

For reference (even if just my own later on), to test this locally, I had to:

Clone the repo
Checkout the relevant branch to test
Run npm i
Run npm run build
Back in the project to test it against, run npm install --save path/to/file (see this StackOverflow answer) to use the local version of the dependency

Then I could test it.

For reference (even if just my own later on), to test this locally, I had to: ...

Here's another way if you want to test it as you did:
npm i; npm run build; npm pack
pack creates a tgz that contains the code that would be released by npm publish. So given that, then you can npm install path/to/morpheus4j-x.y.z.tgz
That's the closest to testing the code as if it were released.
Thanks so much for testing it.


publish mojo missing from 3.6.11

I'm using version 3.6.11 of the provider plugin because I assume it's the latest stable.  When I attempt to run pact:publish  (which btw, seems odd to me because publishing is a consumer action) I get an error:
No plugin found for prefix 'pact' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/Users/jgluck/.m2/repository), artifactory (https://artifactory.tlcinternal.com/artifactory/LC_CENTRAL)] -> [Help 1]
POM looks like so
                <plugin>
                    <groupId>au.com.dius</groupId>
                    <artifactId>pact-jvm-provider_2.12</artifactId>
                    <version>3.6.11</version>
                    <configuration>
                        <pactBrokerUrl>http://localhost:9292</pactBrokerUrl>
                        <pact.verifier.publishResults>true</pact.verifier.publishResults>
                    </configuration>
                </plugin>

When pom looks like this, everything is fine
                    <groupId>au.com.dius</groupId>
                    <artifactId>pact-jvm-provider-maven_2.11</artifactId>
                    <version>3.5.24</version>
                    <configuration>
                        <pactBrokerUrl>http://localhost:9292</pactBrokerUrl>
                        <pact.verifier.publishResults>true</pact.verifier.publishResults>
                    </configuration>
                </plugin>

But I still have to run pact:publish in addition to verify, I assume because the mojo didn't support automatic publishing.
Coincidently, the plugin isn't appearing in Intellij in either case.
I'm probably misunderstanding how all this works.  I've used pact in Ruby and it seems to work slightly differently in Java.

Okay, so I figured out where 3.6.11 is.  This works
                    <artifactId>pact-jvm-provider-maven_2.12</artifactId>
                    <version>3.6.11</version>

mvnrepository has the incorrect info for the plugin.
There's a lot of old information floating around on the internet so it would be nice to have something updated.  I'm happy to submit a PR if you simply tell me where
https://github.com/DiUS/pact-jvm/tree/master/provider/pact-jvm-provider-maven#publishing-pact-files-to-a-pact-broker. This doesn't have the information I'm looking for

Okay, I guess I just need a maven refresher course. Sorry


New Manim version that supports GPU

I get an error in Colab trying to run Manim from "shaders" branch. I see tqdm for each animation, that means they are successful. But then it gets into a loop and I have to stop it with the error:
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/content/manim/manim.py", line 5, in <module>
    manimlib.main()
  File "/content/manim/manimlib/__init__.py", line 14, in main
    scene.run()
  File "/content/manim/manimlib/scene/scene.py", line 77, in run
    self.tear_down()
  File "/content/manim/manimlib/scene/scene.py", line 96, in tear_down
    self.interact()
  File "/content/manim/manimlib/scene/scene.py", line 104, in interact
    self.update_frame()
  File "/content/manim/manimlib/scene/scene.py", line 139, in update_frame
    self.camera.clear()
  File "/content/manim/manimlib/camera/camera.py", line 114, in clear
    rgba = (*Color(self.background_color).get_rgb(), self.background_opacity)
  File "/usr/local/lib/python3.6/dist-packages/colour.py", line 988, in __init__
    self.web = color if color else 'black'
  File "/usr/local/lib/python3.6/dist-packages/colour.py", line 1006, in __setattr__
    fc(value)
  File "/usr/local/lib/python3.6/dist-packages/colour.py", line 1084, in set_web
    self.hex = web2hex(value)
  File "/usr/local/lib/python3.6/dist-packages/colour.py", line 1005, in __setattr__
    fc = getattr(self, 'set_' + label)
KeyboardInterrupt

UPDATE:
If you want to try it in Colab, the code is here.

I am getting the same issue when running in docker. Something to do with the fact that pyglet needs a display to run. There may be a solution using Xvfb

xvfb doesn't work eigher. We need to change manim window.py backend from pyglet to headless.
from moderngl_window.context.headless.window import Window as HeadlessWindow

But I didn't managed to make it work.

Running Win10, I couldn't get it to work when using the preview setting (-p) due to no configs for the window:
Traceback (most recent call last):
  File "C:\Users\Tyler Wolfe-Adam\Documents\Python\manim-shaders\manim.py", line 5, in <module>
    manimlib.main()
  File "C:\Users\Tyler Wolfe-Adam\Documents\Python\manim-shaders\manimlib\__init__.py", line 11, in main
    scenes = manimlib.extract_scene.main(config)
  File "C:\Users\Tyler Wolfe-Adam\Documents\Python\manim-shaders\manimlib\extract_scene.py", line 104, in main
    scenes = get_scenes_to_render(all_scene_classes, config)
  File "C:\Users\Tyler Wolfe-Adam\Documents\Python\manim-shaders\manimlib\extract_scene.py", line 72, in get_scenes_to_render
    scene = scene_class(**scene_kwargs)
  File "C:\Users\Tyler Wolfe-Adam\Documents\Python\manim-shaders\manimlib\scene\scene.py", line 44, in __init__
    self.window = Window(self, **self.window_config)
  File "C:\Users\Tyler Wolfe-Adam\Documents\Python\manim-shaders\manimlib\window.py", line 21, in __init__
    super().__init__(**kwargs)
  File "C:\Program Files\Python37\lib\site-packages\moderngl_window\context\pyglet\window.py", line 54, in __init__
    config=config,
  File "C:\Program Files\Python37\lib\site-packages\pyglet\window\win32\__init__.py", line 130, in __init__
    super(Win32Window, self).__init__(*args, **kwargs)
  File "C:\Program Files\Python37\lib\site-packages\pyglet\window\__init__.py", line 591, in __init__
    config = screen.get_best_config(config)
  File "C:\Program Files\Python37\lib\site-packages\pyglet\canvas\base.py", line 194, in get_best_config
    raise window.NoSuchConfigException()
pyglet.window.NoSuchConfigException

It does work when just writing to a file (-w). However, just for the shape examples. Anything with text doesn't work due to (unrelated) issues with dvisvgm not converting the dvi to svg.

What text doesn't work? tex_mobject or text_mobject?

What text doesn't work? tex_mobject or text_mobject?

Both, unfortunately; I also tried modifying the example scenes with just using one or the other. Both result in OSError: No file matching ./media\Tex\ab47de5016aed0d4.svg in image directory.
I dug into it and it stems from the dvisvgm command (called from the dvi_to_svg function inside \manimlib\utils\tex_file_writing.py) - the command executes successfully but nothing gets outputted (no files or messages, even with the highest level of verbosity). I even tried searching my entire file system for the file and still nothing. It's really weird.
I'm currently getting it setup to try on WSL. Hopefully that works better. No luck on googling the problem either. I'll probably open a new thread somewhere if it doesn't work with WSL :/

Update: Ran into the same problems with the display. Tried using xvfb like so:
xvfb-run -s "-screen 0 640x360x24" python3.7 -m manim example_scenes.py SquareToCircle -ql
That returned the same error for me as when I tried to use the q flag on Windows:
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/tyler/Documents/manim/manim.py", line 5, in <module>
    manimlib.main()
  File "/home/tyler/Documents/manim/manimlib/__init__.py", line 11, in main
    scenes = manimlib.extract_scene.main(config)
  File "/home/tyler/Documents/manim/manimlib/extract_scene.py", line 104, in main
    scenes = get_scenes_to_render(all_scene_classes, config)
  File "/home/tyler/Documents/manim/manimlib/extract_scene.py", line 72, in get_scenes_to_render
    scene = scene_class(**scene_kwargs)
  File "/home/tyler/Documents/manim/manimlib/scene/scene.py", line 44, in __init__
    self.window = Window(self, **self.window_config)
  File "/home/tyler/Documents/manim/manimlib/window.py", line 21, in __init__
    super().__init__(**kwargs)
  File "/home/tyler/.local/lib/python3.7/site-packages/moderngl_window/context/pyglet/window.py", line 54, in __init__
    config=config,
  File "/home/tyler/.local/lib/python3.7/site-packages/pyglet/window/xlib/__init__.py", line 171, in __init__
    super(XlibWindow, self).__init__(*args, **kwargs)
  File "/home/tyler/.local/lib/python3.7/site-packages/pyglet/window/__init__.py", line 591, in __init__
    config = screen.get_best_config(config)
  File "/home/tyler/.local/lib/python3.7/site-packages/pyglet/canvas/base.py", line 194, in get_best_config
    raise window.NoSuchConfigException()
pyglet.window.NoSuchConfigException

Tried again with the w flag, but then got the following error:
Media will be written to ./media/. You can change this behavior with the --media_dir flag.
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/tyler/Documents/manim/manim.py", line 5, in <module>
    manimlib.main()
  File "/home/tyler/Documents/manim/manimlib/__init__.py", line 14, in main
    scene.run()
  File "/home/tyler/Documents/manim/manimlib/scene/scene.py", line 74, in run
    self.construct()
  File "example_scenes.py", line 84, in construct
    self.play(Transform(square, circle))
  File "/home/tyler/Documents/manim/manimlib/scene/scene.py", line 357, in wrapper
    func(self, *args, **kwargs)
  File "/home/tyler/Documents/manim/manimlib/scene/scene.py", line 425, in play
    self.progress_through_animations(animations)
  File "/home/tyler/Documents/manim/manimlib/scene/scene.py", line 402, in progress_through_animations
    self.update_frame(dt)
  File "/home/tyler/Documents/manim/manimlib/scene/scene.py", line 140, in update_frame
    self.camera.capture(*self.mobjects)
  File "/home/tyler/Documents/manim/manimlib/camera/camera.py", line 228, in capture
    shader = self.get_shader(info_group[0])
  File "/home/tyler/Documents/manim/manimlib/camera/camera.py", line 253, in get_shader
    fragment_shader=get_shader_code_from_file(info["frag"]),
  File "/home/tyler/.local/lib/python3.7/site-packages/moderngl/context.py", line 1037, in program
    varyings
moderngl.error.Error: GLSL Compiler failed

fragment_shader
===============
0:179(24): error: `return' with wrong type int, in function `sdf' returning float
``

You can't get hardware acceleration with virtual displays such as xvfb. Can you render SquareToCircle in shaders version correctly?

I was able to do it on mac - not in docker

Can you try to run it in Colab? I had no success there.

Lengthy issue about this in the modengl project: https://github.com/moderngl/moderngl/issues/392
Manim is using moderngl and moderngl-window. I think the main issues is that it extends the pyglet window backend directly. If headless rendering is needed it should use the headless.Window instead.
The BaseWindow.init_mgl_context should be probably also be overridden to create the correct context type or I can add some features for this in the moderngl-window project if we figure out what is needed.

You can't get hardware acceleration with virtual displays such as xvfb. Can you render SquareToCircle in shaders version correctly?

Good to know! I can in Windows, but not in the Ubuntu subsystem. For both the q and w flags I get the pyglet.canvas.xlib.NoSuchDisplayException: Cannot connect to "None" exception.

I released a new version of moderngl-window what should at least solve the NoSuchConfig for a lot of people. You maye also have to go into the window.py module and set samples = 0.
@t-wolfeadam The shader error you are getting is an error in the glsl code here : https://github.com/3b1b/manim/blob/2ce0b72c440fadbfba990bdac8bc9c2ea8bff4e7/manimlib/shaders/quadratic_bezier_fill_frag.glsl#L41
It would return a float. Not all GLSL compilers are nice and convert constants for you automatically. I would fix that line and test it again. Make a PR as well while you are at it (if it works) 😄

I released a new version of moderngl-window what should at least solve the NoSuchConfig for a lot of people. You may also have to go into the window.py module and set samples = 0.

Fantastic, thanks! I can confirm for Windows that updating + setting samples to 0 fixed it!

@t-wolfeadam The shader error you are getting is an error in the glsl code here :
https://github.com/3b1b/manim/blob/2ce0b72c440fadbfba990bdac8bc9c2ea8bff4e7/manimlib/shaders/quadratic_bezier_fill_frag.glsl#L41
It should return a float, not an int. Not all GLSL compilers are nice and convert constants for you automatically. I would fix that line and test it again. Make a PR as well while you are at it (if it works) 😄

Ahh, so that's what sdf was referring to. And will do, cause that also did the trick, so thank you for that as well! (and fortunately, it was the only instance).

@t-wolfeadam Yep. We just sorted out a PR after discussing the issue on the manim discord server 👍

And here it is:
https://github.com/3b1b/manim/pull/950

I tried running the project for SIR simulation (https://www.youtube.com/watch?v=gxAaO2rsdIs) and got this error:  "~\Anaconda3\envs\manim\lib\site-packages\pyglet\canvas\base.py", line 194, in get_best_config
raise window.NoSuchConfigException()
pyglet.window.NoSuchConfigException "
I was able to run the Test case but basically everything else crashed

NoSuchConfigException is related to a hardcoded samples = 1 in the window. That needs to be removed or be configurable. The branch is super alpha and needs a bit of hacking to work.

@einarf

NoSuchConfigException is related to a hardcoded samples = 1 in the window. That needs to be removed or be configurable. The branch is super alpha and needs a bit of hacking to work.

I got it to work by removing the samples  = 1 line, but it is sluggish, could you explain how to make it configurable?

@einarf I found that we can skip the loop when running -w option to write directly to a file. I set HeadlessWindow and backend='egl'. But got an exception with XOpenDisplay. Do you know how to fix that?
!python3 -m manim example_scenes.py SquareToCircle -w

Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/content/manim/manim.py", line 5, in <module>
    manimlib.main()
  File "/content/manim/manimlib/__init__.py", line 11, in main
    scenes = manimlib.extract_scene.main(config)
  File "/content/manim/manimlib/extract_scene.py", line 104, in main
    scenes = get_scenes_to_render(all_scene_classes, config)
  File "/content/manim/manimlib/extract_scene.py", line 72, in get_scenes_to_render
    scene = scene_class(**scene_kwargs)
  File "/content/manim/manimlib/scene/scene.py", line 51, in __init__
    self.camera = self.camera_class(**self.camera_config)
  File "/content/manim/manimlib/camera/camera.py", line 65, in __init__
    self.init_context(ctx)
  File "/content/manim/manimlib/camera/camera.py", line 77, in init_context
    self.ctx = moderngl.create_standalone_context()
  File "/usr/local/lib/python3.6/dist-packages/moderngl/context.py", line 1466, in create_standalone_context
    ctx.mglo, ctx.version_code = mgl.create_context(glversion=require, mode=mode, **settings)
  File "/usr/local/lib/python3.6/dist-packages/glcontext/__init__.py", line 76, in create
    return x11.create_context(**kwargs)
Exception: (standalone) XOpenDisplay: cannot open display

The stack trace above is from another context creation. Maybe that's the one that is used when no preview is used and the HeadlessWindow thing is not needed at all? : https://github.com/3b1b/manim/blob/ec4a70ad3511805c3b5ec55b43ac548be85555e8/manimlib/camera/camera.py#L77
XOpenDisplay means it's and x11 headless context and not egl, and clearly backend='egl' is not passed in there.

Thanks. I replaced it with
self.ctx = moderngl.create_standalone_context(require=460, backend='egl')

ran
!python3 -m manim example_scenes.py SquareToCircle -w

and got rendered file
/content/manim/media/videos/example_scenes/1440p60/SquareToCircle.mp4

One problem: there is no GPU acceleration. On CPU this SquareToCircle example finishes in 17 seconds. On GPU it took 18 seconds. When GPU works the rendering time should be around 3 seconds. Is there anything we can do with it?

hmm. Grab the self.ctx.info and paste here.

{'GL_ALIASED_LINE_WIDTH_RANGE': (1.0, 10.0),
 'GL_CONTEXT_PROFILE_MASK': 1,
 'GL_DOUBLEBUFFER': False,
 'GL_MAJOR_VERSION': 4,
 'GL_MAX_3D_TEXTURE_SIZE': 16384,
 'GL_MAX_ARRAY_TEXTURE_LAYERS': 2048,
 'GL_MAX_CLIP_DISTANCES': 8,
 'GL_MAX_COLOR_ATTACHMENTS': 8,
 'GL_MAX_COLOR_TEXTURE_SAMPLES': 32,
 'GL_MAX_COMBINED_ATOMIC_COUNTERS': 98304,
 'GL_MAX_COMBINED_COMPUTE_UNIFORM_COMPONENTS': 231424,
 'GL_MAX_COMBINED_FRAGMENT_UNIFORM_COMPONENTS': 233472,
 'GL_MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS': 231424,
 'GL_MAX_COMBINED_SHADER_STORAGE_BLOCKS': 96,
 'GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS': 192,
 'GL_MAX_COMBINED_UNIFORM_BLOCKS': 84,
 'GL_MAX_COMBINED_VERTEX_UNIFORM_COMPONENTS': 233472,
 'GL_MAX_COMPUTE_ATOMIC_COUNTERS': 16384,
 'GL_MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS': 8,
 'GL_MAX_COMPUTE_SHADER_STORAGE_BLOCKS': 16,
 'GL_MAX_COMPUTE_TEXTURE_IMAGE_UNITS': 32,
 'GL_MAX_COMPUTE_UNIFORM_BLOCKS': 14,
 'GL_MAX_COMPUTE_UNIFORM_COMPONENTS': 2048,
 'GL_MAX_COMPUTE_WORK_GROUP_COUNT':<PHONE_NUMBER>, 65535, 65535),
 'GL_MAX_COMPUTE_WORK_GROUP_INVOCATIONS': 1536,
 'GL_MAX_COMPUTE_WORK_GROUP_SIZE': (1536, 1024, 64),
 'GL_MAX_CUBE_MAP_TEXTURE_SIZE': 32768,
 'GL_MAX_DEPTH_TEXTURE_SAMPLES': 32,
 'GL_MAX_DRAW_BUFFERS': 8,
 'GL_MAX_DUAL_SOURCE_DRAW_BUFFERS': 1,
 'GL_MAX_ELEMENTS_INDICES': 1048576,
 'GL_MAX_ELEMENTS_VERTICES': 1048576,
 'GL_MAX_ELEMENT_INDEX':<PHONE_NUMBER>,
 'GL_MAX_FRAGMENT_ATOMIC_COUNTERS': 16384,
 'GL_MAX_FRAGMENT_INPUT_COMPONENTS': 128,
 'GL_MAX_FRAGMENT_SHADER_STORAGE_BLOCKS': 16,
 'GL_MAX_FRAGMENT_UNIFORM_BLOCKS': 14,
 'GL_MAX_FRAGMENT_UNIFORM_COMPONENTS': 4096,
 'GL_MAX_FRAGMENT_UNIFORM_VECTORS': 1024,
 'GL_MAX_FRAMEBUFFER_HEIGHT': 32768,
 'GL_MAX_FRAMEBUFFER_LAYERS': 2048,
 'GL_MAX_FRAMEBUFFER_SAMPLES': 32,
 'GL_MAX_FRAMEBUFFER_WIDTH': 32768,
 'GL_MAX_GEOMETRY_ATOMIC_COUNTERS': 16384,
 'GL_MAX_GEOMETRY_INPUT_COMPONENTS': 128,
 'GL_MAX_GEOMETRY_OUTPUT_COMPONENTS': 128,
 'GL_MAX_GEOMETRY_SHADER_STORAGE_BLOCKS': 16,
 'GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS': 32,
 'GL_MAX_GEOMETRY_UNIFORM_BLOCKS': 14,
 'GL_MAX_GEOMETRY_UNIFORM_COMPONENTS': 2048,
 'GL_MAX_INTEGER_SAMPLES': 32,
 'GL_MAX_PROGRAM_TEXEL_OFFSET': 7.0,
 'GL_MAX_RECTANGLE_TEXTURE_SIZE': 32768,
 'GL_MAX_RENDERBUFFER_SIZE': 32768,
 'GL_MAX_SAMPLES': 32,
 'GL_MAX_SAMPLE_MASK_WORDS': 2,
 'GL_MAX_SERVER_WAIT_TIMEOUT': -1,
 'GL_MAX_SHADER_STORAGE_BLOCK_SIZE':<PHONE_NUMBER>,
 'GL_MAX_SHADER_STORAGE_BUFFER_BINDINGS': 96,
 'GL_MAX_TESS_CONTROL_ATOMIC_COUNTERS': 16384,
 'GL_MAX_TESS_CONTROL_SHADER_STORAGE_BLOCKS': 16,
 'GL_MAX_TESS_EVALUATION_ATOMIC_COUNTERS': 16384,
 'GL_MAX_TESS_EVALUATION_SHADER_STORAGE_BLOCKS': 16,
 'GL_MAX_TEXTURE_BUFFER_SIZE': 134217728,
 'GL_MAX_TEXTURE_IMAGE_UNITS': 32,
 'GL_MAX_TEXTURE_LOD_BIAS': 15,
 'GL_MAX_TEXTURE_SIZE': 32768,
 'GL_MAX_UNIFORM_BLOCK_SIZE': 65536,
 'GL_MAX_UNIFORM_BUFFER_BINDINGS': 84,
 'GL_MAX_UNIFORM_LOCATIONS': 65536,
 'GL_MAX_VARYING_VECTORS': 31,
 'GL_MAX_VERTEX_ATOMIC_COUNTERS': 16384,
 'GL_MAX_VERTEX_ATTRIBS': 16,
 'GL_MAX_VERTEX_ATTRIB_BINDINGS': 16,
 'GL_MAX_VERTEX_ATTRIB_RELATIVE_OFFSET': 2047,
 'GL_MAX_VERTEX_OUTPUT_COMPONENTS': 128,
 'GL_MAX_VERTEX_SHADER_STORAGE_BLOCKS': 16,
 'GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS': 32,
 'GL_MAX_VERTEX_UNIFORM_BLOCKS': 14,
 'GL_MAX_VERTEX_UNIFORM_COMPONENTS': 4096,
 'GL_MAX_VERTEX_UNIFORM_VECTORS': 1024,
 'GL_MAX_VIEWPORTS': 16,
 'GL_MAX_VIEWPORT_DIMS': (32768, 32768),
 'GL_MINOR_VERSION': 6,
 'GL_MIN_MAP_BUFFER_ALIGNMENT': 64,
 'GL_MIN_PROGRAM_TEXEL_OFFSET': -8.0,
 'GL_POINT_FADE_THRESHOLD_SIZE': 1.0,
 'GL_POINT_SIZE_GRANULARITY': 0.125,
 'GL_POINT_SIZE_RANGE': (1.0, 189.875),
 'GL_RENDERER': 'Tesla P100-PCIE-16GB/PCIe/SSE2',
 'GL_SAMPLE_BUFFERS': 0,
 'GL_SMOOTH_LINE_WIDTH_GRANULARITY': 0.125,
 'GL_SMOOTH_LINE_WIDTH_RANGE': (0.5, 10.0),
 'GL_STEREO': False,
 'GL_SUBPIXEL_BITS': 8,
 'GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT': 256,
 'GL_VENDOR': 'NVIDIA Corporation',
 'GL_VERSION': '4.6.0 NVIDIA 418.67',
 'GL_VIEWPORT_BOUNDS_RANGE': (-65536, 65536),
 'GL_VIEWPORT_SUBPIXEL_BITS': 8}

When we replaced manim window.py with the code below it redered faster, but we've got into a loop.
import moderngl_window as mglw
from moderngl_window.context.headless.window import Window as HeadlessWindow
from moderngl_window.timers.clock import Timer

from manimlib.constants import DEFAULT_PIXEL_WIDTH
from manimlib.constants import DEFAULT_PIXEL_HEIGHT
from manimlib.utils.config_ops import digest_config

class Window(HeadlessWindow):
    size = (DEFAULT_PIXEL_WIDTH, DEFAULT_PIXEL_HEIGHT)
    fullscreen = False
    resizable = False
    gl_version = (4, 6)
    vsync = False
    samples = 1
    cursor = False

    def __init__(self, scene, **kwargs):
        digest_config(self, kwargs)
        super().__init__(**kwargs)
        self.scene = scene
        self.title = str(scene)
        # Put at the top of the screen
        self.position = (self.position[0], 0)

        mglw.activate_context(window=self)
        self.timer = Timer()
        self.config = mglw.WindowConfig(ctx=self.ctx, wnd=self, timer=self.timer)
        self.timer.start()

    # Delegate event handling to scene
    def pixel_coords_to_space_coords(self, px, py, relative=False):
        return self.scene.camera.pixel_coords_to_space_coords(px, py, relative)""")

Hard to say about performance to be honest. Manim in shader branch is a mix of gpu and cpu rendering as far as I have seen, so that needs to be profiled locally. If this is Google Colab still I would guess you only won't get the performance of that entire card. Also I don't know if there's any setup or teardown cost.

So does it create two opengl contexts when not using a preview?

I don't know. How can I check that?

Add some prints before every context creation or open and append something to file if you cannot see output.

It creates context in /content/manim/manimlib/camera/camera.py
And does not in /usr/local/lib/python3.6/dist-packages/moderngl_window/context/headless/window.py

I think we have to create HeadlessWindow in addition to moderngl.create_standalone_context(require=460, backend='egl').

The camera.py one is slower I guess? .. and you only saw one single context creation I hope?
You can try commenting out blending and see if that affects anything
self.ctx.enable(moderngl.BLEND)
self.ctx.blend_func = (
    moderngl.SRC_ALPHA, moderngl.ONE_MINUS_SRC_ALPHA,
    moderngl.ONE, moderngl.ONE
)

The second thing you can test is to use same framebuffer configuration as the window.

The camera.py one is slower

Yes

you only saw one single context creation I hope?

Yes. The conext creates in camera.py.

You can try commenting out blending and see if that affects anything

Rendering took 17 seconds

Modify get_fbo() to make the same framebuffer format? I don't understand why changing the window class affects anything in the first place 😄

I tried this:
def init_context(self, ctx=None):
    if ctx is not None:
        self.ctx = ctx
        self.fbo = self.ctx.detect_framebuffer()
    else:
        self.ctx = moderngl.create_standalone_context(require=460, backend='egl')
        size = (DEFAULT_PIXEL_WIDTH, DEFAULT_PIXEL_HEIGHT)
        samples = 1
        self.fbo = self.ctx.framebuffer(
          color_attachments=self.ctx.texture(size, 4, samples=samples),
          depth_attachment=self.ctx.depth_texture(size, samples=samples),
        )
    self.background_fbo = None

Rendering time 15 seconds, but the resuling file is a black window.

Modify get_fbo() to make the same framebuffer format?

I'm not sure what you mean.

I don't understand why changing the window class affects anything in the first place 😄

It does not affect anything when writing to a file enabled !python3 -m manim example_scenes.py SquareToCircle -w.
But it affects when running headless widow: !python3 -m manim example_scenes.py SquareToCircle.

I think we need to recreate steps you did in window.py inside manim camera.py.

Probably a good idea. It might just even be a fluke. I don't really know how much gpu resources is allocated per user or if the tesla have a much lower latency. I'm guessing the setup is configured to do longer running gppgu and machine learning tasks.
I'd try to experiment over several runs. Try to replicate the speedup you saw.
One difference I see is in scene.py/update_frame. If you have a window it will call swap_buffers. That's just doing a ctx.finish() that will wait for all rendering operations to complete.

I believe when you are connected to Colab GPU you are getting all its power.
Do you know how to setup antialiasing samples in /content/manim/manimlib/camera/camera.py?

Do it in get_fbo and restore ```python
# Methods associated with the frame buffer
def get_fbo(self):
return self.ctx.framebuffer(
color_attachments=self.ctx.texture(self.size, 4, samples=8),
depth_attachment=self.ctx.depth_texture(self.size, samples=8),
)
Restore `init_context` to the original state except the backend part.

This returns black video with colored artifacts at the bottom edge.
Your example shows white screen with this settins:
import numpy as np
from PIL import Image
import moderngl

ctx = moderngl.create_standalone_context(require=460, backend='egl')
samples = 8
fbo = ctx.framebuffer(
        color_attachments=ctx.texture((512, 512), 4, samples=samples),
        depth_attachment=ctx.depth_texture((512, 512), samples=samples)
    )
fbo.use()

vertices = np.array([
    -1.0,  -1.0,   1.0, 0.0, 0.0,
     1.0,  -1.0,   0.0, 1.0, 0.0,
     0.0,   1.0,   0.0, 0.0, 1.0],
    dtype='f4',
)

prog = ctx.program(vertex_shader="""
#version 330
in vec2 in_vert;
in vec3 in_color;
out vec3 color;
void main() {
    gl_Position = vec4(in_vert, 0.0, 1.0);
    color = in_color;
}
""",
fragment_shader="""
#version 330
out vec4 fragColor;
in vec3 color;
void main() {
    fragColor = vec4(color, 1.0);
}
""",
)
vao = ctx.simple_vertex_array(prog, ctx.buffer(vertices), 'in_vert', 'in_color')
vao.render(mode=moderngl.TRIANGLES)

image = Image.frombytes('RGBA', (512, 512), fbo.read(components=4))
image = image.transpose(Image.FLIP_TOP_BOTTOM)
image.save('triangle.png', format='png')

@einarf Investigating this further I found that it is possibly a bug of the Moderngl.

Oh. I'll have to look into that. Thanks!

@einarf Do you have any comments on this?

Not anything that I've already said in the post above.
I'm wondering if manim even needs a depth buffer, so you can try dropping it.

Can you tell when a depth buffer is needed?

Search for DEPTH_TEST in the source. That`s the enum name for the flag that enables or disable depth testing.

I found that for now manim has gpu accleration only when it works with pyglet window:
!python3 -m manim example_scenes.py SquareToCircle -p

What I didn't find is where pyglet window defines a framebuffer and where it uses samples=1.


ctrl+f "donate" on main page leads to 0 results

pls tell me how to donate, this app has saved me countless weeks


Chunk Index record doesn't tell me how big my chunk record is

After reading a chunk index record, I know which message index record to read, but I don't know how big my chunk record is which means I have to go read the size of the record and then go read the record itself.

+1

Change offset to start_offset and end_offset so we can identify the bytes in the file containing the opcode+record lengh+record data for a chunk index record.

chunk_start_offset - points to an opcode
chunk_end_offset - one past the end of the chunk
[start_offset, end_offset)

Add chunk_trailer_byte_length? chunk_trailer_end_offset?

https://github.com/foxglove/mcap/tree/roman/spec-format/docs/specification#chunk-index-op0x05


Set order for markdown files

Please describe.
It's necessary to be able to order the pages
Describe the solution you'd like
Possibly using the frontmatter (see first iteration of blueprints)
Describe alternatives you've considered
Have not considered alternatives - but open to it?

I got this working and will send a PR soon 😄

closing per 139  thanks @protoEvangelion !


@Drawing doesn't work with non-English labels

This works:
@Drawing[precipiceopen] @Trigger[click]  @Scene[uC8Dx07uojgY6lPx]{Απόκρημνος Τομέας}
This doesn't work:
@Drawing[Απόκρημνος Τομέας] @Trigger[click]  @Scene[uC8Dx07uojgY6lPx]{Απόκρημνος Τομέας}

This is a specific problem due to the tiny mce editor/html strings.
If I paste the string
Απόκρημνος Τομέας
I get
Απόκρημνος Τομέας
as the string to match against which of course fails.
I will need to give this some thrught, but if you know a good way to preprocess the text so that it becomnes a UTF string I can compared against it would be much easier.

On my PR #58, i bypassed this issue by using directly the id like this:
@Drawing[uD8asx05uojgY6lPx] @Trigger[click] @Scene[uC8Dx07uojgY6lPx]
is not the perfect solution, but i think is acceptable

On my PR #58, you can do this:
@Drawing[*] @Tag[my_english_label_reference]@Trigger[click] @Scene[uC8Dx07uojgY6lPx]{Απόκρημνος Τομέας}
For each drawing element (with any Russian or Japanese label) in the current scene, filter by all those that have the 'my_english_label_reference' tag, in this case you decide by setting the tags if for one or more drawing elements. In this way your players will see the writing in the native language, while trigger happy use the English name set in the element '@Tag' for retrieve and start the trigger


Make extension check case insensitive

Hopefully this will fix the MP3 extension issue?

Lint suggests this isn’t a solution…


federate target error with net/http request canceled

hi, my prometheus server will federate metrics from the other prometheus. net/http request canceled occurs after a day of running.

prometheus runtime information

I built the binary from master yesterday.

prometheus targets

http_request_duration_microseconds{handler="federate"}

no related errors in prometheus log

i had checked the federate target's response is about 64 MegaBytes. is there a option to enable gzip?

i'm using the prometheus-.17.0 all the time before updating to 0.19.1, the federation always work correctly. so,i will roll back to 0.17.0 and test it again.
any change on it or any suggestion?  thanks a lot.

Pre-0.19 had a bug that would not honor the set timeout properly. Your error message looks like you are hitting the timeout while retrieving metrics.
Federation can sometimes be somewhat slow (but was sped up a lot with 0.18). In your case, I'd try to increase the timeout configured for the federation target (and increase the scrape interval if needed, the latter cannot be smaller than the former).

@beorn7  thanks for your reply.
yes, it is a little slow to federate metrics from the other one. if i enlarge the federation interval, whether i will lose some metrics at some timestamp?
take for example:

prometheus B scrap metrics from exporters every 5 seconds.
prometheus A federate metrics from prometheus B every 30 seconds.

is it means that prometheus A will miss 25 seconds data ?
thanks.

The resolution on your federating server will then indeed be lower than the resolution on the server you are federating from. Some users deliberately use this setup for downsampling.
No averaging is applied, you will always federate the latest possible value of each series.

the samples of the federate targets is too large to get back in time. thanks. closing it.


weird version tags in release notes

See here: https://github.com/googleapis/nodejs-compute/pull/669 (not the PR body which I edited, but the contents of CHANGELOG.md):

These 3.1.0 and v3.1.0 things are weird. I suspect they might be coming from using Release-As: feature in the commit messages, but not sure.

This is happening because we are parsing Release-As commits into the notes field with title: RELEASE AS. We are using conventional-changelog-writer under the hood which is interpreting that note as a BREAKING CHANGE
See: https://github.com/conventional-changelog/conventional-changelog/issues/815


Started Conversion to golang

Changes

Dockerfile for golang
Docker Compose file for postgres nginx and the golang api
Created the basic structure with bun ORM and gofiber framework

Closing because bun has some problems and so will switch to gorm


utilize fetch_dags_in_cluster instead of checking filelocations to determine how dags land in clusters

Closing because we commit this PR directly onto the lyft-test-2.3.4 branch


Support for style copy

Hello Dmitry, this is very nice. I appreciate the speed your implementation provide.
I have a question, do you intend to add support for simple style copy instead of doodle based on mask file? This is a simpler alternative that I found to provide better results at times.
Regards

Hey, I'm sorry, I do not understand what "simple style copy" is.. Isn't it the style copy which is done by artistic style algorithm? Please detail.
Dmitry

Hi, perhaps style transfer is a better term. The command with from neural-doodle when doing style-transfer vs Image Analogy is:
python3 doodle.py --style samples/Gogh.jpg --content samples/Seth.png
--output SethAsGogh.png --device=cpu --iterations=40
In that case there is no need to provide a mask. Just a simple style and content image.

Well, if my method is extended to style transfer it naturally becomes artistic style :) So there's nothing new I can do, I suppose.


dubbo plugin "Generic invocation" will throw exception when dubbo version below 2.7.3

Question
dubbo "Generic invocation" support "async invoke" on version 2.7.3. if we use dubbo version 2.7.2, it will throws exception.
the dubbo plugin "generic invocation" method may change to sync type?

the apache dubbo ?   add dubbo version ,

the apache dubbo ? add dubbo version ,

yes, the apache dubbo，that means telling users to use apache dubbo higher than version 2.7.3?

CompletableFuture<Object> future = genericService.$invokeAsync(metaData.getMethodName(), pair.getLeft(), pair.getRight());
apache dubbo only supports this method after version 2.7.3,
so that, users who use soul apache dubbo plugin need use apache dubbo higher than version 2.7.3

You can wrap the $invoke method with CompletableFuture.

You can wrap the $invoke method with CompletableFuture.

I don't understand😂

@KevinClair I can fix this problem , I think it don't need 'async call' , I wan't to change it to 'sync call ' , It is OK ?

@KevinClair I can fix this problem , I think it don't need 'async call' , I wan't to change it to 'sync call ' , It is OK ?

Yes，you can send a pull request. However, I mean if it's not work in the version of apache dubbo  less than 2.7.3, you can wrap the $invoke method with CompletableFuture.
public interface GenericService {

    /**
     * Generic invocation
     *
     * @param method         Method name, e.g. findPerson. If there are overridden methods, parameter info is
     *                       required, e.g. findPerson(java.lang.String)
     * @param parameterTypes Parameter types
     * @param args           Arguments
     * @return invocation return value
     * @throws GenericException potential exception thrown from the invocation
     */
    Object $invoke(String method, String[] parameterTypes, Object[] args) throws GenericException;

    default CompletableFuture<Object> $invokeAsync(String method, String[] parameterTypes, Object[] args) throws GenericException {
        Object object = $invoke(method, parameterTypes, args);
        if (object instanceof CompletableFuture) {
            return (CompletableFuture<Object>) object;
        }
        return CompletableFuture.completedFuture(object);
    }

}


bench: update the go-tpc dependency

Signed-off-by: mahjonp<EMAIL_ADDRESS>
What problem does this PR solve?
See https://github.com/pingcap/go-tpc/pull/44
What is changed and how it works?
We have solved the problem in go-tpc, and this PR only update its dependency.
Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code

Code changes

Has exported function/method change
Has exported variable/fields change
Has interface methods change
Has persistent data change

Side effects

Possible performance regression
Increased code complexity
Breaking backward compatibility

Related changes

Need to cherry-pick to the release branch
Need to update the documentation

/test

Codecov Report

Merging #262 into master will decrease coverage by 19.09%.
The diff coverage is 27.71%.

@@             Coverage Diff             @@
##           master     #262       +/-   ##
===========================================
- Coverage   61.22%   42.13%   -19.10%
===========================================
  Files          40       38        -2
  Lines        2298     2950      +652
===========================================
- Hits         1407     1243      -164
- Misses        674     1503      +829
+ Partials      217      204       -13

Flag
Coverage Δ

#coverage
?

Impacted Files
Coverage Δ

cmd/uninstall.go
75.86% <0.00%> (-4.14%)
:arrow_down:

main.go
100.00% <ø> (ø)

pkg/repository/crypto/keys.go
0.00% <0.00%> (ø)

pkg/repository/v0manifest/component.go
26.66% <0.00%> (ø)

pkg/repository/v1manifest/key_store.go
0.00% <0.00%> (ø)

pkg/repository/v1manifest/local_manifests.go
0.00% <0.00%> (ø)

pkg/repository/v1manifest/manifest.go
0.00% <0.00%> (ø)

pkg/repository/v1manifest/repo.go
0.00% <0.00%> (ø)

pkg/repository/v1manifest/types.go
0.00% <0.00%> (ø)

pkg/utils/ioutil.go
36.50% <0.00%> (-7.50%)
:arrow_down:

... and 44 more

Continue to review full report at Codecov.

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

PTAL @lucklove


TFVC Source Control List / Tree Not visible After 1.39 Update

VSCode Version: 1.39
OS Version: Windows Server 2019

Steps to Reproduce:

Open Source control
No list or tree visible

Does this issue occur when all extensions are disabled?: Yes/No

i can confirm; im experiencing the same issue. here is the  stack trace of the  exception
[2019-10-15 10:17:19.012] [renderer1] [error] Cannot set property 'resourceStates' of undefined: TypeError: Cannot set property 'resourceStates' of undefined     at TfvcSCMProvider.onDidModelChange (/home/nuffsaid/.vscode/extensions/ms-vsts.team-1.149.2/out/src/tfvc/tfvcscmprovider.js:128:44)     at l.fire (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:50:539)     at Model.<anonymous> (/home/nuffsaid/.vscode/extensions/ms-vsts.team-1.149.2/out/src/tfvc/scm/model.js:188:31)     at Generator.next (<anonymous>)     at fulfilled (/home/nuffsaid/.vscode/extensions/ms-vsts.team-1.149.2/out/src/tfvc/scm/model.js:8:58)

Fix is out on 1.39.2.


Fix Broken link in Odin project challenge and update first answer - Links and Images Question H

Describe the Issue
We recently got a report of a broken link in the Links and Images Questions H challenge.
Under the assignments section, there is a link to read an article about the different image formats.

However, that link no longer works.
We should use a link from our own fcc publication instead to fix this.
How to contribute
This is a small fix so I am opening this up for contribution for first timers only.
Please read through the fix below and read through our contributing guide.
There will be no assignment for this issue.
Feel free to work on it and create a PR.
How to fix the issue
Here is the file you will be working with
https://github.com/freeCodeCamp/freeCodeCamp/blob/main/curriculum/challenges/english/16-the-odin-project/top-links-and-images/links-and-images-question-h.md
Replace the old link here:
# --assignment--

Read about the  four main image formats that can be used on the web.

with this new change here
# --assignment--

Read about the  four main image formats that can be used on the web.

Also, let's change the first multiple choice answer here
## --answers--

TIFF, GIF, PNG, and SVG.

---

and change it to this new option here
## --answers--

MOV, GIF, PNG, and SVG.

---

Affected Page
https://www.freecodecamp.org/learn/the-odin-project/top-links-and-images/links-and-images-question-h
Your code
N/A
Expected behavior
The link should be replaced with this one here
https://www.freecodecamp.org/news/image-file-types-picture-format-extensions-jpeg-gif-png-svg-tiff/
Screenshots
No response
System

Device: [e.g. iPhone 6, Laptop]
OS: [e.g. iOS 14, Windows 10, Ubuntu 20.04]
Browser: [e.g. Chrome, Safari]
Version: [e.g. 22]

Additional context
No response

Thanks, for the write up, I was the one that made the post! I didn't know FCC was open source on here. I just tried my first pull request for this, thanks!


Build spits out seemingly harmless warning

Let's fix the issue or not warn at all, if it isn't one.
https://dev.azure.com/monacotools/Monaco/_build/results?buildId=145209&view=logs&j=4d2898ab-dfbe-557e-92e7-aaac158fdd2f&t=bf591f68-b11f-58a5-2795-b482f67ba1e7&l=14
https://github.com/microsoft/vscode/blob/0573777298ff29b19606818635752c7a702321a3/build/lib/util.ts/#L355

I wouldn't say it's a harmless warning. jschardet doesn't provide a main or browser entrypoint in their package.json which means we have no idea where to load it from. I assume there's a dist/*.min.js file but don't actually check just because I knew there was one for jschardet. This is extremely flaky in that if we add additional packages in the future without the same file structure they won't load if they don't provide an entrypoint. The real fix is this PR being merged https://github.com/aadsm/jschardet/pull/73

The maybe let's log it for any package other than the ones we hardcode assumptions to: for now that's jschardet only.

I've suppressed the jschardet warning. Ideally when that PR is added we can warn or even error out on all non entrypoint packages because it is really something to be careful of since the loader has no way of knowing.


"readFile" is not exported by "__vite-browser-external"

I'm able to run and see SVGs during development, however when I attempt to build I get the following error:
"readFile" is not exported by "__vite-browser-external", imported by "node_modules/vite-plugin-solid-svg/dist/es/index.mjs".

1: import { readFile } from 'node:fs/promises';
            ^
2: import { loadConfig, optimize } from 'svgo';
error during build:
RollupError: "readFile" is not exported by "__vite-browser-external"

I've been able to repeat this issue with a bare-minimum code sandbox: https://codesandbox.io/p/sandbox/vite-solid-svgs-m5mvzw?file=%2Fsrc%2FApp.tsx%3A7%2C19
You will see the SVG rendered properly but if you attempt to run yarn build it will throw the error.

@Kikketer This plugin reads SVG source to transform it to JSX. I was wondering myself how this should be done correctly. I tried via this.load(), but with no success.

Seems like a pretty critical bug figuring you can’t build the application.

Seems like a pretty critical bug figuring you can’t build the application.

It should work locally
As of your error, seems like node dependencies are externalized in your environment

Building locally doesn't work either, the codesandbox was just an example of repeating the issue.
Is there a solution to this?  I'm not sure what you mean by "externalized in your environment"

Building locally doesn't work either, the codesandbox was just an example of repeating the issue. Is there a solution to this? I'm not sure what you mean by "externalized in your environment"

I looked up your example and you're trying to use plugin in runtime/browser for some reason

This is incorrect usage, it should only be uses in vite.config.ts in plugins sections. As I said, this plugin depends on node fs module.

Seems to me a bit of documentation update is needed. I'm not sure where I would have put the SolidSvg configuration.
I've since dropped this library, simply made my SVGs into TS files, then dropped SolidJS and moved on to using a new tech stack.
Thanks


[FR] Run playbook based on status (w/o service call)

Checklist

[X] I have filled out the template to the best of my ability.
[X] This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
[X] This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.
n/a
Describe the solution you'd like
I would love to have the option to run a playbook based on the status of the device, without the need of a start and stop service.
states:
  idle: idle.csv
  pause: pause.csv
  off: off.csv

Every time the status changes, the playbook should start from the beginning
Describe alternatives you've considered
n/a
Additional context
A status change should stop the current running playbook and start the playbook mapped to the new state.

I will consider this

Implemented with #2170
See:
https://homeassistant-powercalc.readthedocs.io/en/latest/strategies/playbook.html#active-playbook-based-on-state-trigger
I cannot do for OFF state as this is a special case in Powercalc, and needs fundamental changes on different places.
Will be in next release.
You could test it by installing the master branch with HACS.

I will consider this. Do you use YAML or GUI?

Would be great! I use the GUI.

@EddyK69 Ok, I only implemented in YAML yet. Will have a look if I can also implement for the GUI.

Thnx! That was a quick one! Is use the GUI btw. Will test this asap

Added for GUI with #2176

Thnx, but cannot download Master via HACS: get a 404 on
https://github.com/bramstroker/homeassistant-powercalc/releases/download/master/powercalc.zip

Hi @bramstroker
I tried to download master many times, and it already fails wirh 404. I think the access right for that folder are restricted to your account. Maybe you can make the path to https://github.com/bramstroker/homeassistant-powercalc/releases/download/master/powercalc.zip public  readable?!

@erkr Strange you both are having issues. I cannot make that path available as master is not a release, but just the main branch where releases are made from.
A zip file is only build when a new release / version is being issued.
HACS shouldn't try to download powercalc.zip, but rather clone the repository.
Maybe something changed in HACS why this is not working anymore, it was working in the past.
I'll have a look.

I have found following issue on HACS issue tracker:
https://github.com/hacs/integration/issues/3513
It was working in the past, but apparently it does not work anymore when the integration uses zip releases, which is what powercalc does and is the preferred way.
According to the developer of HACS it's not something which will be fixed in HACS, which is a pitty.
So there it not much I can do unfortunately.
If you want to you could download manually. And replace config/custom_components/powercalc with the contents of custom_components/powercalc. It's a littlebit more work, but it's essentially the same as HACS automates.

@bramstroker
Great you found out that it simply doesn't work. I propose to just  remove the master from the release list. You currently release so actively, that I can wait for the next one ☺

@bramstroker Great you found out that it simply doesn't work. I propose to just remove the master from the release list. You currently release so actively, that I can wait for the next one ☺

That not something I can fix in Powercalc, that's also a HACS issue.
When zip_release is used they should just hide the master branch from the list.
That's also suggested by other integration developers in the issue link I shared.
https://github.com/hacs/integration/issues/3513#issuecomment-1949471720

I recall from another project that a version must be set in the manifest when you copy the files manually

I'm pretty confident that's not required. You can just overwrite the files manually and restart and it should load the new code.

Today I'm with family, but I will give it a try tomorrow 👍

@EddyK69 I see, there was actually a problem with the translation keys, causing the labels not correctly rendered.
Will be fixed in next version.
The correct field is this one:

@bramstroker Thnx. Found the hidden field 😄
But unfortunately i cannot get it working the way i thought it should:
I configured a device with a simple on/off state:

And added 2 playbooks in de config/powercalc/playbooks folder:
cat test-on.csv
1,10
2,20
3,30
5,50
10,100

cat test-off.csv
1,100
2,50
3,30
5,20
10,10

The 'On' playbook seems to work, but the 'Off' playbook doesn't. After switching the device to Off, power is set to 0 immediately and after switching it On again, the playbook doesn't seem to start from the
beginning:
https://github.com/bramstroker/homeassistant-powercalc/assets/13943630/c3482d27-86f6-4408-ab46-705086e774b0
I would expect that the playbook start over again after every state-change, right?

@EddyK69 Did you see one of my first comments after I implemented?
https://github.com/bramstroker/homeassistant-powercalc/issues/2160#issuecomment-2027983565
off state cannot be used for playbook.
I will have a quick look if I can find a way to implement without needing to modify too much.

Have good news, because it was a quicky. Should be fixed with #2210

Have good news, because it was a quicky. Should be fixed with #2210

Quick indeed! Wil try it again soon, thnx!

Have good news, because it was a quicky. Should be fixed with #2210

Quick indeed! Wil try it again soon, thnx!

Will be in next release. not sure when yet. maybe this weekend

Still doesn't seem to work unfortunately :(
https://github.com/bramstroker/homeassistant-powercalc/assets/13943630/43438603-14a6-4f7d-984b-799282689603

@EddyK69 You are sure you are at v1.11.8 now?
Or are you running beta version of powercalc?

@EddyK69 You are sure you are at v1.11.8 now? Or are you running beta version of powercalc?
@bramstroker Yep, I'm sure.

It worked once: switching ON started started to increase the power (see below how the playbooks are defined) and switiching OFF started to decrease, only once!  I tried to restart the integration but that did not fix it.

cat test-on.csv
1,10
2,20
3,30
5,50
10,100

cat test-off.csv
1,100
2,50
3,30
5,20
10,10

Ok thanks for the extra information. Will have a look if I can reproduce and fix.

Should be fixed with #2229. According to the unit tests this should fix the issue.
I'll also do some testing on my develop HA instance.

Ok thanks for the extra information. Will have a look if I can reproduce and fix.

Thnx! Just updated to V1.12.0 and it seems that is now not starting the OFF-playbook anymore :(

It's working for me now:
https://github.com/bramstroker/homeassistant-powercalc/assets/2345875/91fe1fcc-c441-4a88-b6fa-0b7e01200ca3
You can try by editing config/custom_components/powercalc/strategy/playbook.py and add following to line 95:
https://github.com/bramstroker/homeassistant-powercalc/blob/09f2feca624ed8f772d6f3d504ed8786c330a172/custom_components/powercalc/strategy/playbook.py#L95
Restart HA afterwards.

Thanx @bramstroker for the quick fix! Wil try out this weekend

Yep, works perfectly now! Thanx @bramstroker !


Shuttle walls visual change

About the PR
Makes shuttle walls use the plastinum sprites from /tg/ but edited to be brighter, also ports the old shuttle windows (using para sprites.)
Also removes interior shuttle walls; I have no clue what to do with them visually right now & the design of shuttle walls is probably too complex to simplify to something better. The current ones look pretty bad as well. If someone wants to readd them with better sprites then they're free to.
Why / Balance
Our current shuttle wall sprites are great, but don't really fit at all - they're basically in a completely different style compared to every other wall in the game.
These sprites are by no means perfect, but should make it easier to do visually interesting stuff with shuttles later on + will probably look a little better once shuttle tiles are resprited and properly usable in shuttles.
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
:cl:

tweak: New shuttle wall sprites.
remove: Removed interior shuttle walls.

not sure how i feel about this. like you say the current shuttle walls are pretty good. i think the current ones will look significantly less out of place when we get actual good shuttle tiles

and im not sure they even look particularly out of place right now

Yeah, don't remove the interior walls. Don't use them if you don't want but they are used elsewhere.

I dont like these new sprites as they are currently

imo the ones we have fit fine, ive never once looked at them and thought they were out of place. these ones are objectively less shuttle looking and more insane asylum looking

Okay, I'm a bit late here, but here's my rationale...
Artstyle concerns:

Left: current shuttle walls, Middle: /vg/station shuttle walls, Right: proposed shuttle wall changes.
Outside of being relatively perspective-agonistic like the rest of our walls are (for the most part,) I feel like my assessment that these are made completely differently compared to most other walls in the game is likely pretty spot-on. They're fairly visually complex and sharp-looking. I won't really knock the blue-adjacent coloration much though, as they are literally meant to be made out of titanium. It arguably makes sense, though if you think it does personally is probably up for debate.
Doing interesting stuff with shuttles in the future:
This is mainly just conceptual and doesn't really hold as much weight (hell, this might even just flat out be outside my artistic capabilities,) but I eventually wanted to try making cool FTL / Goonstation external shuttle parts like this (the image on this post) or this. I feel like it's fairly unlikely that the current style of shuttle walls will allow me to do this, due to their inner grey filling. I may just not be thinking hard enough about it, though, as I haven't actually tried making that yet.

DAMN IT I posted that way too early, I forgot to finish what I was writing.
There's one other component to this: as far as I'm aware, the proposed shuttle walls might be our best bet for a replacement with all of the above factors considered. The classic /vg/ ones are pretty good looking and fit the artstyle well, but look bad next to steel tiles due to their high brightness (they need to be used with shuttle tiles to look good,) and will also cause minor breakage here since these need to also use the alternate wall smoothing mode to work.
(random image nabbed from google images showcasing the /vg/ shuttle walls in question)

with all that being said, though, I've already finished shuttle tiles that are at least marginally better then what we have now. I should probably just PR those and wait for them to be mapped first to figure out what to do, like what mirror suggested.


fix: trino thread app missing full context

SUMMARY
Fixes the issue where Trino SQL execution was missing Flask's g values in the context.
Flask's requests and g are local to the request thread or greenlet, by creating a new thread we loose this context.
This PR passes a copy of g into the thread, g is then recreated inside the thread, this g will be local to the thread but will contain all the necessary context of the current flask request
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

Thank you for the review @michael-s-molina


Update harden-update-ad-fs-pingfederate.md

The 2.4.x.0 versions have been released for download, and not autoupgrade.

@billmath
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


[RESOLVED] Interface eth0(): High error rate (>2 for 5m)

Problem started at 08:30:29 on 2023.05.25
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Operational data: errors in: 1, errors out: 0
Original problem ID: 22417
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23483&eventid=22417

Problem has been resolved in 3m 0s at 08:33:29 on 2023.05.25
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Original problem ID: 22417


Issue: RPC response error -32002

I am getting the following error RPC response error -32002. I have looked previous issues and seen there was a problem with people using the wrong account but I believe I am using the right one. From the Solscan view I am using the token address. Is this the right one?

What command are you running and can you post the full error here?

Sure thing, I am running update uri and getting the following
`Error: RPC response error -32002: Transaction simulation failed: Error processing Instruction 0: custom program error: 0x7 [5 log messages]
Caused by:
RPC response error -32002: Transaction simulation failed: Error processing Instruction 0: custom program error: 0x7 [5 log messages]`

You're using the wrong update authority:
0x7:
	Token Metadata            |	UpdateAuthorityIncorrect: Update Authority given does not match

You're using the wrong update authority:
0x7:
	Token Metadata            |	UpdateAuthorityIncorrect: Update Authority given does not match

So I need to be running these commands from the update authority account?

So I need to be running these commands from the update authority account?

So I need to be running these commands from the update authority account?

You can only update the metadata of a NFT if 1) the is_mutable flag is set to true and 2) if you're the update authority, so you need to use that keypair when you run metaboss update or set commands.

So I need to be running these commands from the update authority account?

You can only update the metadata of a NFT if 1) the is_mutable flag is set to true and 2) if you're the update authority, so you need to use that keypair when you run metaboss update or set commands.

Ok thank you

Ok thank you

hi, im also this error when trying spl-token create token
RPC response error -32002: Transaction simulation failed: Error processing Instruction 0: custom program error: 0x0 [3 log messages]
i dont know if its my keypair path or config file or my default signer  is lost or not set up. appreciate the help anyone.


Minimum node version requirement: >=8.0.0

Starting with v12.0.0 the minimum node version requirement for discord.js will be >=8.0.0 to make use of features like async/await, Object.entries(), Object.values() (ES2017) etc.
This will allow us to implement features like #1376 easily and without further obstacles.
Full feature list for 8.0.0:
nodejs/node#12220
Since this will be a rather big breaking change users that want to use discord.js v12.x.x will need to update their node version to at least 8.0.0. The reason why we don't plan on supporting >=7.0.0 is that --harmony is way too unreliable and unstable in versions prior to 7.6.0 (e.g. memory leaks) .
Benefits:

Full access to ES2017 features

async / await

Object.entries()

Object.values()

Drawbacks:

Dropping node 6/7 support

for build:
now: add v8(-nightly) (and v9(-nightly) when it releases)
after v11.1 is released: remove v6/v7 builds

This is live now, forcing node 8 will be done in around 1 week or a as soon as we start using features that are not compatible with node 6 anymore.

As of 375b89a9 this is now implemented in master.

Hurray!

I believe this is now resolved in #3180, since URLSearchParams are global in Node.js 10+.

Bumped to v12

If v12 is the minimum, for the ShardingManager, how much flexibility is there with defaulting to worker mode and using SharedArrayBuffer to share memory between instances? Workers were made stable as part of v12
Things like users, presences, and probably more could be cut down on for memory usage savings. Unfortunately I'm not as familiar with this as I started looking into it just recently.


Install protoc-gen-go-vtproto

Summary
This gives us the ability to squeeze performance out of proto. protoc-gen-gogo is long deprecated since the SDK upgrade to v2.
Repo: https://github.com/planetscale/vtprotobuf
Blog: https://vitess.io/blog/2021-06-03-a-new-protobuf-generator-for-go/
Test Plan
make build:

Closed by #31


Should we activate the thread safe feat by default

Problem
I got bitten by a threading issue. What is the reason for not activating the thread safe flag by default? It will ease the usage of the library.
Also I think evolving the API to have a clear separation (or a flag) to have the transaction blocking or not blocking will clarify the API. It feel weird to have non-asynchronous call doing non-blocking execution; e.g. httpx is doing both but it is clear if you are doing blocking or non-blocking execution.

Thanks for the quick reply

What is the reason for not activating the thread safe flag by default?

Are you refering to the Doc's allow_multithreading parameter?

Yes it is.

If so, it is turned off by default because if multithreading is not needed then we save the cost of acquiring a thread lock when requesting a new transaction, which has to be done in a seperate thread.

Do you have reference to share about that cost?

It feel weird to have non-asynchronous call doing non-blocking execution; e.g. httpx is doing both but it is clear if you are doing blocking or non-blocking execution.

You mean non-blocking transactions created with with doc.transaction():? This might reuse an existing transaction, which is probably what one wants most of the time. I think the API is quite clear: we want a transaction, not necessarily a new transaction. Otherwise, we explicitly require one with with doc.new_transaction(): or its async equivalent.

Ok
Actually, I'm confused by that sentence in the documentation:
https://github.com/jupyter-server/pycrdt/blob/a15dc9b148a498d1c252b2a56a013603ac14d91e/docs/usage.md?plain=1#L91
More specifically "This method will never block, and should be used most of the time."
Is the transaction finished when we exist the with doc.transaction or is the transaction queued for processing?

Do you have reference to share about that cost?

I mean, we wait for a thread lock in another thread here. That relies on the operating system's thread scheduling, which has to be much slower than just a few function calls in the same thread. This is one of the reasons async programming is much faster than multithreading, for IO-bound operations. If you are not convinced, you can try a FastAPI application that uses def handler(). It is an order of magnitude slower than using async def.
See also this issue in Yrs.

Is the transaction finished when we exist the with doc.transaction or is the transaction queued for processing?

The transaction finishes when the outer-most transaction finishes. So if there was already a with doc.transaction(): upper in the stack, the changes will be committed when this context manager exits.

Thanks for all the details - closing the issue.


SEED Claiming Guide

Claim Your Seeds!
So you got some SEED's for doing something, well that's GREAT !!!!
First things first, you'll need to check the Seed Sheet to see how many seeds you’ve earned.
Then you can head on over to the MetaGame DAO, open the Tokens app, click SEED, click Add tokens, then add your Ethereum address and the number of SEEDs you'd like. This will open a vote in the DAO for current SEED holders to read and review.

Link to SEED claiming GIF walk through: https://imgur.com/MT19Wdt

Turns out, SEED holders are busy planting for the future. If you want SEED holders to give you SEEDs, give them a good reason to!  Do it on Discord. Do it on Twitter. Shill here, shill there, shill yourself everywhere. Let everyone know about all your SEEDs that are coming. The more you shill, the more likely you are to produce SEEDs! Shill! Shill! Shill!

Pro tip: drop into the MetaGame Discord and shill MetaGame whales like @Hammad, @PEth, and @Yalor

If your request is legit, you should see your tokens in your wallet in the near future. Haven’t gotten your Seeds yet? We recommend obsessively checking the status of open votes in the MetaGame DAO. 🤪

Dropping this here so that it's easy to reference or extend in the future

The latest and greatest version of this guide is here: https://metagame.trydiscourse.com/t/metagame-seed-claiming-guide/21

My understanding is that the current link is https://forum.metagame.wtf/t/metagame-seed-claiming-guide/21
Can probably close this issue.