Component and View Colocation

Currently, components live in a dedicated app/components directory. This has worked well so far, but we'd like to explore a more unified approach.
This isn't set in stone, but the goals would be to:

Allow components to be defined in app/views
Enable render "users/show", user: current_user to render a component instead of explicitly referring to the component class. e.g. This would be equivalent to render Users::Show.new(user: current_user)
Remove the Component suffix from components so their names have a 1-to-1 mapping to view directories. e.g. app/views/users/user.rb would map to class Users::User < ViewComponent::Base

A more complete example may look like:
# app/controllers/users_controller.rb
class UsersController < ApplicationController
  def show
    user = User.find(params[:id])
    render :show, user: user
  end
end

# app/views/users/show.rb
class Users::Show < ViewComponent::Base
  def initialize(user:)
    @user = user
  end
end

<%# app/views/users/show.html.erb %>

<%= @user.name %>'s page!

   <%= render "users/profile_content", user: user # will render the app/views/users/profile_content.rb component %>

part of https://github.com/github/view_component/issues/617

Related: https://github.com/github/view_component/discussions/588

I've spiked this out a bit here: https://github.com/BlakeWilliams/view_component-rails-test (PR's showing off other ideas or approaches are welcome)
Some take-aways:

_ prefixed file names for use as partials doesn't feel like the correct approach for components.
Using strings, e.g. render "users/profile, user: user" instead of render Users::Profile.new(user) has some limitations, like requiring that component arguments are keyword arguments.

How would render User::Profile.new(user) translate to render "user/profile? The component would be required to change the initializer from def initialize(user) to def initialize(user:).

Implicit controller renders may be tricky or impractical.

I think the flexibility of view components (e.g. user defined initializers) may make it more challenging to make them work with Rails as seamlessly as we'd like, but I'll keep experimenting with it.

@BlakeWilliams I actually prefer the explicit object instantiation over using strings. Makes it easier to refactor and also makes it clearer that it is a "component" and not a partial. Would be OK with being able to use both ways though as a matter of user preference.
At the moment I feel like trying to unify view components with the existing rails approach to views seems like it would be a bit inconsistent . View_component encourages a more django-like "views and templates" approach that doesn't seem like it would mesh well.
Perhaps I just need to play around more with it and see how it would work in practice.

#1412 brought this to my attention again. A couple of quick draft thoughts:

It would be good to maintain compatibility with ActionView, for a few reasons:

It might take folks a good while to encapsulate their views
Some folks might not even want to encapsulate all of their views for various reasons – developer friction, perhaps only using one or two helpers in a view, etc.
Maybe the migration path looks something like this:

User has an ActionView template
User adds an associated class in the correct place, inheriting ViewComponent::Base and including something that makes sure helpers are still available
User overrides helpers by adding methods on the component class, and replaces controller instance variables with variables on the component class
User removes the include once they're through with the migration

We may want to provide guidance for handing down things that might have been considered globally before from the controller to the view – things like the current user, tenant (for multitenanted apps), current time, etc.. These are the kinds of things that it helps to have available to us globally and might make a genuine use case for helpers, but it's also good to have visibility over them so that they can be mocked or stubbed in tests
We could do with a codemod/RuboCop autocorrect for rewriting view specs as component specs

Relevant wizardry using Phlex: https://fly.io/ruby-dispatch/component-driven-development-on-rails-with-phlex/
I'm posting it here, since it might shed some light on the above points.

So awesome to see this come to life!

@bradgessler @joeldrapper giving dhh's closing of the Rails PR, what do you think about writing a shared gem for implicit renderable rendering that both ViewComponent and Phlex could share?

Yeah, that makes sense to me. Phlex-Rails could depend on that gem.

@joeldrapper great. Want to pick a name? rails-implicit-renderable-rendering?

@joeldrapper @joelhawksley I really liked this idea, and just put together some code here, mind taking a look https://github.com/reeganviljoen/render_kit


btop: init at 1.0.5

Motivation for this change
Snazzy resource viewer: https://github.com/aristocratos/btop/blob/main/Img/normal.png
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 139018 at 703ab9f1 run on x86_64-linux 1

1 package built successfully:

btop

1 suggestion:

warning: missing-phase-hooks
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/tools/system/btop/default.nix:17:3:
   |
17 |   installPhase = ''
   |   ^

looks like this line is causing aarch64-linux build to fail
https://github.com/aristocratos/btop/blob/v1.0.5/Makefile#L82

Interesting. I didn't realize the default version of gcc is different on aarch64-linux.

Result of nixpkgs-review pr 139018 run on x86_64-linux 1

1 package built:

btop


adds damp rag

About the PR

Adds damp rag that can be made from 1 cloth, and can be butchered back to cloth.
It can be used like a mop to clean up puddles, but only holds 30u of liquid.
This should make enable people to clean up small messes on their own instead of waiting for janitor.
Also adds 2 rags to booze locker to help bartenders clean the bar a bit easier.
Media

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

Changelog

:cl:

add: NT employees now know how to make damp rags from cloth, it can clean up some mess but holds less liquid.

could you not just make cloth itself an absorber

What happens to the absorbed liquids if you deconstruct the damp rag?
Won't that create a system where you don't need drains and all of the "bad" liquids would just disappear in thin air as you indefinitely use the same piece of cloth?

yeah thats another good reason to just have cloth be absorbing liquids itself

What happens to the absorbed liquids if you deconstruct the damp rag? Won't that create a system where you don't need drains and all of the "bad" liquids would just disappear in thin air as you indefinitely use the same piece of cloth?

Oh didn't think that through

i would just make this not deconstructible

Should probably just be called rag, then it can also be used to make molotovs etc


#4278 Add log details for metadata load when app startup

Fixes #4278
Changes proposed in this pull request:

Add log details for metadata load when app startup

Codecov Report

Merging #4295 into master will decrease coverage by 0.28%.
The diff coverage is 78.94%.

@@             Coverage Diff              @@
##             master    #4295      +/-   ##
============================================
- Coverage     59.37%   59.08%   -0.29%
  Complexity      352      352
============================================
  Files          1016     1020       +4
  Lines         17453    17529      +76
  Branches       3112     3132      +20
============================================
- Hits          10362    10357       -5
- Misses         6438     6517      +79
- Partials        653      655       +2

Impacted Files
Coverage Δ
Complexity Δ

...e/init/loader/impl/DefaultTableMetaDataLoader.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...pt/metadata/loader/EncryptTableMetaDataLoader.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...e/metadata/loader/ShardingTableMetaDataLoader.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...ngsphere/underlying/common/log/MetaDataLogger.java
100% <100%> (ø)
0 <0> (?)

...c/core/context/SingleDataSourceRuntimeContext.java
93.33% <100%> (+1.66%)
0 <0> (ø)
:arrow_down:

...ore/context/MultipleDataSourcesRuntimeContext.java
94.44% <100%> (+1.11%)
0 <0> (ø)
:arrow_down:

...egistry/config/listener/SchemaChangedListener.java
70% <0%> (-17.5%)
0% <0%> (ø)

...ternal/registry/config/node/ConfigurationNode.java
88% <0%> (-6.74%)
0% <0%> (ø)

...estration/center/instance/NacosConfigInstance.java
65.78% <0%> (-0.88%)
0% <0%> (ø)

...ngsphere/sql/parser/visitor/PostgreSQLVisitor.java
0% <0%> (ø)
0% <0%> (ø)
:arrow_down:

... and 14 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 f10a097...fd2a026. Read the comment docs.

Pull Request Test Coverage Report for Build 9515

15 of 19 (78.95%)  changed or added relevant lines in 6 files are covered.
6 unchanged lines in 4 files lost coverage.
Overall coverage increased (+0.01%) to 62.879%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

encrypt-core/encrypt-core-common/src/main/java/org/apache/shardingsphere/encrypt/metadata/loader/EncryptTableMetaDataLoader.java
0
1
0.0%

sharding-core/sharding-core-execute/src/main/java/org/apache/shardingsphere/sharding/execute/metadata/loader/ShardingTableMetaDataLoader.java
0
1
0.0%

shardingsphere-underlying/shardingsphere-common/src/main/java/org/apache/shardingsphere/underlying/common/metadata/table/init/loader/impl/DefaultTableMetaDataLoader.java
0
2
0.0%

Files with Coverage Reduction
New Missed Lines
%

encrypt-core/encrypt-core-common/src/main/java/org/apache/shardingsphere/encrypt/metadata/loader/EncryptTableMetaDataLoader.java
1
0%

sharding-core/sharding-core-execute/src/main/java/org/apache/shardingsphere/sharding/execute/metadata/loader/ShardingTableMetaDataLoader.java
1
0%

shardingsphere-underlying/shardingsphere-common/src/main/java/org/apache/shardingsphere/underlying/common/metadata/table/init/loader/impl/DefaultTableMetaDataLoader.java
1
0%

sharding-orchestration/sharding-orchestration-core/src/main/java/org/apache/shardingsphere/orchestration/internal/util/IpUtils.java
3
76.0%

Totals

Change from base Build 846:
0.01%

Covered Lines:
11022

Relevant Lines:
17529

💛  - Coveralls

A new suggestion:
Can we consider about log the table one by one, it makes the loading looks like active. So the log format should be:
Loading metadata, total tables: %s
Loading table %s 1
Loading table % s2
...
Loading table %s n
Loading metadata finished, cost %s miles


Android integration not working

I followed your instructions to get it integrated into Android and hit this error when building:

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.2/userguide/command_line_interface.html#sec:command_line_warnings
FAILURE: Build failed with an exception.

Where:
Build file '/Users/fabian/Projects/jpmedia/supermarket-swap-app/android/app/build.gradle' line: 184

What went wrong:
A problem occurred evaluating project ':app'.

Supplied String module notation 'rn-text-detector' is invalid. Example notations: 'org.gradle:gradle-core:2.2', 'org.mockito:mockito-core:1.9.5:javadoc'.

In the app/build.gradle file of you packag. Add
implementation files('rn-text-detector')
instead of
implementation 'rn-text-detector'
It should compile. Enjoy coding.

In the android/app/build.gradle file of your project, add
implementation files('rn-text-detector')
instead of
implementation 'rn-text-detector'
It should compile. Enjoy coding.

Thanks. This works

In the android/app/build.gradle file of your project, add
implementation files('rn-text-detector')
instead of
implementation 'rn-text-detector'
It should compile. Enjoy coding.

Answer

Please update the documentation in npm

implementation '@react-native-google-signin/google-signin'

> Supplied String module notation '' is invalid. Example notations: 'org.gradle:gradle-core:2.2', 'org.mockito:mockito-core:1.9.5:javadoc'.

why is not working?


Update and consolidate vcharts documentation with main documentation

This includes the html files in the vcharts/examples directory, which currently serve as a model for how to set the data up for each chart type.

Dup of #75 which is closed.


iCloud3, Beta 14 (3/9/2023) has been uploaded

@avd706 @B-Hartley @broyuken @bgnzo818 @beyondwatts
@confusedsecuritydudes @chupacabra71 @chr04213
@denac @derekoharrow @diothar
@Exit2Studios @freshairr @gekberlin @garyak
@hvddrift @hellotomtom @JtwoA @J-Fartz @kalkocz @kamkilt @kingy444
@lukkigi @marceloaf @MarkGardiner @mobiledude @myMartek
@pauly7300 @poudenes @polskikrol
@rdstodda @spamsal @Seger85 @scotty1395
@townsmcp @tm24fan8 @t077584 @u20p17
Important Links:
Download - Go to the iCloud3 Releases page here. Select Assets, then select icloud3-beta-#.zip. Download the zip file and unzip it into the /config/icloud3 directory. Then restart HA.
iCloud3 v3 Documentation - It is still in process, does not include the latest updates to iCloud3 and can be found here
Change Logs - They can be found here

Change Log

iCloud Account Authentication:

When the iCloud Account is verified using a password, a session access token is created and stored
as a cookie. The password login also generates an email saying someone has logged into your iCloud
account. This beta changes the method of authenticating the account to using the token first and
then using the password if it has expired. This should eliminate or greatly reduce the login emails
generated by Apple.
Did a lot of code cleanup in the account authentication routines to insure the 2fa-code is requested
when needed, to be able to reauthenticate and log into the current account with a new password and to
be able to log into a different account in the Configuration Wizard.

Configuration Wizard > iCloud Account Credentials screen - Updated it to improve readability and make
it easier to set up the account information. Several rare problems were also fixed where (1) logging
into an iCloud Account with an incorrect password would still allow access when there was a valid token
and (2) logging into an iCloud Account with a changed password would not work if the token has expired.
Now, logging in with a new password causes a new 2fa request to be made.
Zone enter/leave event for an iCloud3 device_tracker entity - This can now be used as an automation
trigger.
Latitude/longitude values - They are now stored as numeric fields in the device_tracker attributes instead
of a string field. They are now displayed with 2-decimal places on a Lovelace device_tracker/attributes
window (an HA limitation). A new gps attribute has been added to display the latitude/longitude with it's
full precision.
Passive Zones - Fixed a problem where passive zones could be selected. Also found out that the iOS App
will generate enter/exit triggers for passive zones. These will now be ignored by iCloud3.
Configuration Wizard > Sensors screen - Changed it  for readability and to list the important sensors
first.
Event Log - Made some minor formatting changes. Also added a new icon to the top-right of the Event Log
so you can become an iCloud3 Stargazer. Click it to go to the iCloud3_v2 GitHub repository. Then click
the star in the top-right corner.
Distance Sensors:
(1) Changed the distance precision so the distance value is within 6-inches/1-millimeter of the
measurement between the device and the zone center - (4-decimal places for miles, 5 for meters)
(2) Changed the moved_distance sensor to display in feet/meters when less than 1mi/1km
(3) Changed the _moved_distance to display the distance from one poll to the next when in a zone
(4) Added attribute to _moved_distance sensors:
_moved_from shows the from location time
_moved_to shows current location time
(5) Added attribute to all zone_distance sensors:
_meters_distance shows the distance in meters to the zone with 5-decimal place accuracy,
_meters_distance_to_zone_edge shows the distance in meters to the edge of the zone
(6) Added attribute to all zone_distance sensors:
_miles_distance shows the distance in miles to the zone with 4-decimal place accuracy if the
unit_of_measure is miles.

Thanks - great update!!


shields: Settle on nodelabels naming scheme

When using shields with boards, it may happen that shields and board both describe use the same nodelabel (to describe the same device: sensor, display, ..), leading to a conflict at device tree compilation.
For instance, same node label 'lsm6dsl' is used for both board and shield description:
https://github.com/zephyrproject-rtos/zephyr/blob/eafc4f875b7443bceffe7f8bee14aa97d7ca4bd6/boards/shields/x_nucleo_iks01a2/x_nucleo_iks01a2.overlay#L28-L30
https://github.com/zephyrproject-rtos/zephyr/blob/eafc4f875b7443bceffe7f8bee14aa97d7ca4bd6/boards/arm/b_l4s5i_iot01a/b_l4s5i_iot01a.dts#L113-L115
This was discussed initially in https://github.com/zephyrproject-rtos/zephyr/issues/48780.
Conclusion of the discussion was to use, in shields device tree description, the following device nodelabel naming scheme:
<device>_<address>
Then https://github.com/zephyrproject-rtos/zephyr/pull/50034 was merged using a different approach:
<device>_<shield_name>
Reason is that <device>_<address> will give conflicts (in dtc) when using multiple shields using devices at same address but on different busses.
Note that this proposal was initially rejected in #48780 because not concise enough.
Aim of this issue is to settle on agreement that can be applied in all cases, document it and update in-tree shields accordingly

I think it makes sense

@MaureenHelm  ?

Agree this makes sense

Agree this makes sense

ok, thanks. I'll update

Closing, as #50526 was merged


MIMIC-CXR test results

Hi,
Thanks for your great contributions.
Is that possible that you could provide the test results of the best checkpoint, as we want to do some evaluation compared with the RGRG model?
Thanks

Hello,
all results published in our paper are test results of the best checkpoint.
Could you elaborate on what you mean?
Best,
Tim

Hi Ethan,
I would have to first check with the authors of MIMIC-CXR if we can legally share the generated reports.
I will get back to you once I have the answer.
Best,
Tim

Yesterday, I reached out to the authors via email.
While awaiting their response, there's an alternate way should you urgently require the generated reports. First, create the test set csv files by running 'create_dataset.py.' Following this, execute 'test_set_evaluation.py' which will produce a 'generated_reports.txt.' This file will comprise both the generated and reference reports.
Bear in mind that due to the substantial size of the test set (32,711 images), the evaluation process is time-consuming. Our evaluation run took approximately three days utilizing a single Nvidia A40. Although somewhat laborious, this method provides a viable alternative for procuring the generated reports.

Thank you for your suggestions. We will try it later.

I've received a response from the authors. They recommended that I publish the reports as a credentialed resource on PhysioNet. Doing so would enable the sharing of the reports under the same access restrictions as those applicable to MIMIC-CXR.
However, this approach involves a comprehensive data preparation stage followed by a rigorous peer review process (which would take a considerable amount of time). After considering these requirements, I believe generating the reports directly would be a more time-efficient solution.
Nevertheless, should there be increased demand for the generated reports, I am open to considering the publication route on PhysioNet to facilitate broader access.

Yesterday, I reached out to the authors via email.
While awaiting their response, there's an alternate way should you urgently require the generated reports. First, create the test set csv files by running 'create_dataset.py.' Following this, execute 'test_set_evaluation.py' which will produce a 'generated_reports.txt.' This file will comprise both the generated and reference reports.
Bear in mind that due to the substantial size of the test set (32,711 images), the evaluation process is time-consuming. Our evaluation run took approximately three days utilizing a single Nvidia A40. Although somewhat laborious, this method provides a viable alternative for procuring the generated reports.

After 'create_dataset.py.' I run 'test_set_evaluation.py' but get:


(Roots 3/Mystical World)Model problems

im using:
forge:<IP_ADDRESS>15
mystical lib:1.1.1
mystical world:1.2.0
patchouli:1.0-17
roots:3.0.0-2
ok there are a few problems with models .firstly the knives from mystical world and the 2 from roots have the normal item model not the tool one.the tool from roots(living hoe,axe etc)suffer from the same problem.and also all armors that should have 3d armors just show the "no texture"texture on the default armor model.

The armors dont yet have models indeed, thats a known issue.

Also what do you mean that there is something wrong with the models. Eveyrthing looks fine, can you provide pictures?

they are held like normal items(cakes,cookies etc) and not like tools.

Oh like that, I'll take a look


Need to filter variants based on availability for all queried experiments

Querying multiple experiments, like experiment_id = ['historical','ssp585'], will yield all variants available for each respective experiment. However, the variants of 'historical' that are not available for 'ssp585' may not be desired, so it would be good to filter these out before the analysis.
One way to do so may be to match datasets on all attributes except for experiment_id, and then throw out variants that do not have all experiment_id's.

try
.search(
    ...,
    require_all_on=['source_id', 'member_id'],
)

That makes sure that all experiments are given for a single member/source combination.

Perfect!


Wait for paint to finish during repaintGraphics.

For RUN-2643 (https://linear.app/replay/issue/RUN-2643)
Main thread gets woken up too early because the logic for waking it up is in the wrong callback method.  We want it in OnPaintFinished, not OnRepaintFinished.
We currently call OnRepaintFinished when immediately after we call OnBeginFrameDerivedImpl on the scheduler, but by this point only layout has been done, and the draw may or may not have completed (or even started).
This change fixes things to remove OnRepaintFinished, and instead use OnPaintFinished to trigger the event that the PaintWhenDiverged is waiting on after we receive and encode the pixmap data for the paint.

Tested the fix against master, and against a reference build, and it clearly works.
The logic also makes sense: of course we'd want to notify the main thread when the paint data gets deposited, and NOT immediately after we've submitted a begin-frame to the draw code.

ProxyMain code runs on the main thread, and ProxyImpl code runs on the compositor (impl) thread.  The painting should happen within the ProxyImpl::RecordReplayRepaint method (before OnRepaintFinished gets called) and if it's not I want to see the stack for when it does happen.
We can land this patch as is but there is still a major hole in our understanding of the problem here.

@bhackett1024: ProxyMain code runs on the main thread, and ProxyImpl code runs on the compositor (impl) thread. The painting should happen within the ProxyImpl::RecordReplayRepaint method (before OnRepaintFinished gets called)

It does look like RecordReplayRepaint (or rather OnBeginFrameDerivedImpl) has a synchronous paint mode:
if (settings_.using_synchronous_renderer_compositor) {
  BeginImplFrameSynchronous(args);
  return true;
}

Maybe replacing OnBeginFrameDerivedImpl with BeginImplFrameSynchronous would help (and maybe a good idea, since it reduces asynchrony)? But either way, knowing exactly what happens when first, would be helpful.

ProxyMain code runs on the main thread, and ProxyImpl code runs on the compositor (impl) thread. The painting should happen within the ProxyImpl::RecordReplayRepaint method (before OnRepaintFinished gets called) and if it's not I want to see the stack for when it does happen.
We can land this patch as is but there is still a major hole in our understanding of the problem here.

This is the stack for the the paint itself:
"recordreplay::Trace(char.const*,....)+141",
    "viz::SoftwareOutputDevice::EndPaint()+36",
    "viz::SoftwareRenderer::FinishDrawingFrame()+121",
    "viz::DirectRenderer::DrawFrame(std::Cr::vector<std::Cr::unique_ptr<viz::AggregatedRenderPass,.std::Cr::default_delete<viz::AggregatedRenderPass>.>,.std::Cr::allocator<std::Cr::unique_ptr<viz::AggregatedRenderPass,.std::Cr::default_delete<viz::AggregatedRenderPass>.>.>.>*,.float,.gfx::Size.const&,.gfx::DisplayColorSpaces.const&,.std::Cr::vector<gfx::Rect,.std::Cr::allocator<gfx::Rect>.>)+3140",
    "recordreplay::SubmitCompositorFrame(viz::LocalSurfaceId.const&,.viz::CompositorFrame.const&)+953",
    "cc::mojo_embedder::AsyncLayerTreeFrameSink::SubmitCompositorFrame(viz::CompositorFrame,.bool)+708",
    "cc::LayerTreeHostImpl::DrawLayers(cc::LayerTreeHostImpl::FrameData*)+1029",
    "cc::ProxyImpl::DrawInternal(bool)+468",
    "cc::Scheduler::DrawIfPossible()+133",
    "cc::Scheduler::ProcessScheduledActions()+1128",
    "cc::Scheduler::OnBeginImplFrameDeadline()+194",
    "base::DeadlineTimer::OnScheduledTaskInvoked()+45",
    "base::DefaultDelayedTaskHandleDelegate::RunTask(base::OnceCallback<void.()>)+35",
    "base::internal::Invoker<base::internal::BindState<void.(base::DefaultDelayedTaskHandleDelegate::*)(base::OnceCallback<void.()>),.base::WeakPtr<base::DefaultDelayedTaskHandleDelegate>,.base::OnceCallback<void.()>.>,.void.()>::RunOnce(base::internal::BindStateBase*)+159",
    "base::TaskAnnotator::RunTaskImpl(base::PendingTask&)+257",
    "base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::LazyNow*)+1001",
    "base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()+127",
    "non-virtual.thunk.to.base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()+21",
    "base::MessagePumpDefault::Run(base::MessagePump::Delegate*)+154",
    "base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool,.base::TimeDelta)+355",
    "base::RunLoop::Run(base::Location.const&)+461",
    "blink::scheduler::NonMainThreadImpl::SimpleThreadImpl::Run()+232",
    "base::(anonymous.namespace)::ThreadFunc(void*)+86",
    "recordreplay::Thread::ThreadMainOwnStack(void*)+96",
    "InvokeOnNewStack+11"

I think I know why you're confused here: DeadlineTimer::OnScheduleTaskInvoked here is invoked from a timer:
void DeadlineTimer::ScheduleNewTask(TimeTicks deadline,
                                    subtle::DelayPolicy delay_policy) {
  DCHECK_CALLED_ON_VALID_SEQUENCE(sequence_checker_);
  is_running_ = true;

  if (!timer_callback_) {
    timer_callback_ =
        BindRepeating(&DeadlineTimer::OnScheduledTaskInvoked, Unretained(this));
  }
  delayed_task_handle_ = GetTaskRunner()->PostCancelableDelayedTaskAt(
      base::subtle::PostDelayedTaskPassKey(), posted_from_, timer_callback_,
      deadline, delay_policy);
}

So maybe my "fix" is actually working because it allows the deadline timer to do a proper re-paint, and the one we invoked via ProxyImpl::RecordReplayRepaint still got short-circuited.

I'll land this if it passes CI, but I'll also investigate the sequence of events more carefully to see what's happening and fix it properly if needed.


Tab press after swipe is not working

react-native-router-flux 4.0.0-beta.26
react 16.8.3
react-native 0.59.4
Actual Behaviour:
I have 4 tabs, ex: Products, Profile, Code, Help. When we swipes between tabs, it is working properly, but after swipe when I tap on tab, it is not redirecting to initial Scene of the tab.
I have used legacy={true}, but it is not working.

I'm having a similar behavior in my project.
"react-native-router-flux": "^4.0.6",
"react": "16.9.0",
"react-native": "0.60.5",

Current Behavior:
I have 5 tabs. If I dont swipe anytime, the tab items actually works fine. But, if I swipe once, then the tab icons doesnt work anymore (and I only allowed to change scenes by swipping between them. )
Tried to convert my tabBarIcons to touchableOpacities that, on press, make an router-flux action to redirect to the current scene (something like... ActionskeyScene), but this change didnt worked at all. Also tried to overrite the tabBarOnPress child functions to behave exactly as described above, but this doesnt worked to me neither.


Implement ElevatedView and Elevation extension on UWP

What would you like to be added:
ElevatedView and elevation extension compile right now but don't display any shadow.
Why is this needed:
To look the same on all platforms
For which Platform:

[x] UWP

Anything else we need to know?
The contribution would need to be in Uno directly

It would probably be something like themeshadow?
https://docs.microsoft.com/en-us/windows/uwp/design/layout/depth-shadow

@MatFillion  Why is this part of Material and not in Uno ?

This is why it's required, but the pr needs to be done in uno

Other notes. ElevatedView inside a splitview causes abnormal and funky rectangular shadows (android/ios)


Set cache_classes to true in threaded worker

This fixes the 'A copy of TwitterStream has been removed from the module
tree but is still active!' exception when running in development
environment.
There is probably a smarter way to properly unload the TwitterStream class and maybe even support code reloading, but I wasn't able to find it. :smile:

Will this cause reloading issues in development?

Before rails 4.2 I always had to restart the background worker in development to pick up the changes, don't know if that changed recently.

Spec failure is something random, ordering related?

Right, I will have a look at that spec tomorrow and enforce ordering.

Updated the PR to revert #770, which fixes #783. Also set cache_classes = false in bin/schedule.rb which fixes #770 when running it on development.
Since the background workers needed to be restarted to pick up code changes in development even with cache_classes set to false it think this is the easiest way to fix all of the problems we had. And this still fixes #799  :smile:

LGTM!

It's been working for me.

Superseded by cfe8482c0d6eca95e7324aa266caacccc4ffd46f and #806

Working!

Awesome!


📎 Create script to run in CI to verify the correctness of the commit messages

We already have a parser and some log inside changelog.ts.
We want to have a script to run in the CI that checks if the commit message follows the conventional-commit guidelines/rules.

This is a great idea. Note that while I think it's smart to provide local tooling to verify commit messages, I also think that we should rely on a well-tested GitHub Action if possible, similar to how we use them for other CI tasks already. I don't think we necessarily have to recreate a conventional-commit verification mechanism.

Is there a GitHub action for that already? If so, we could add it!


Tuning to 950Mhz fails

Trying to tune my USB3 device to 950MHz fails.

Aborted (core dumped)

Using test_xtrx gives the following:
jessie@jessie-ThinkPad-T530:~/xtrx/libxtrx/build$ ./test_xtrx -t -f 950e6
22:25:59.470635 WARN:   [PCIE] XTRX PCIe driver isn't loaded
22:25:59.634796 WARN:   [3380] IO thread: Unable to set realtime priority: error 1
CPU Features: SSE2+ SSE4.1+ AVX+ FMA-
Master: 32.000 MHz; RX rate: 4.000 MHz; TX rate: 0.000 MHz
Failed xtrx_tune: -2

Is there something else I need to do in order to tune to 950MHz? Or is this a hardware limitation of the Fractional VCO?

This was just a software bug. Update all libs to the latest revision.


Coveralls not working properly on Travis builds

This is a persistent problem, probably started with migration to Ubuntu 20.04 (for the build, not docker images).

This problem doesn't impact build status, but coverage reports are not synced.

No longer using Travis CI nor Coveralls, but GitHub Actions and Codecov.


DBZ-5221 Conditionalize entry in metrics table as upstream content

DBZ-5221
Add community conditional to NumberOfOversizedTransactions metric in the Oracle connector documentation.
Tested in local Antora and downstream builds.

@roldanbob this LGTM as it is. Let us know how it goes in the downstream build.

Thanks, @Naros. I tested this in a downstream build and can confirm that the conditionalized  content is not shown, so this is all set now.

Thanks @roldanbob, applied to main only.


🎉 3.0.6

ℹ About this release

Version: 3.0.6
Type: patch
Last Release: 3.0.5 (11/10/2022, 4:13:56 PM) [?]
Commits to merge: 18 [?]

📦 Dependencies

Update node-fetch from ^3.2.10 to ^3.3.0
Update puppeteer from ^19.2.2 to ^19.3.0

📦 Development Dependencies

Update @semantic-release/changelog from ^6.0.1 to ^6.0.2
Update @types/mocha from ^10.0.0 to ^10.0.1
Update @types/node from ^18.11.9 to ^18.11.11
Update @typescript-eslint/eslint-plugin from ^5.42.0 to ^5.45.0
Update @typescript-eslint/parser from ^5.42.0 to ^5.45.0
Update eslint from ^8.26.0 to ^8.29.0
Update typedoc from ^0.23.16 to ^0.23.21
Update typescript from ^4.8.4 to ^4.9.3

:tada: This PR is included in version 3.0.6 :tada:
The release is available on:

v3.0.6
GitHub release
Docker container (sebbo2002/iubh-campus-sync:3.0.6)
v3.0.6

Your semantic-release bot :package::rocket:


add -o json for delete cmds

What is the purpose of this change? What does it change?
add -o json option for delete commands
Was the change discussed in an issue?
https://github.com/redhat-developer/odo/issues/1383
How to test changes?
run below commands with -o json option and validate it works as defined in the issue #1383
    odo component delete
    odo project delete
    odo storage delete ( yet to push )
    odo url delete

/hold

@syamgk Can you mark this as draft?
We should wait until https://github.com/redhat-developer/odo/pull/1395/files#diff-6c6a7fefe37261e2fa8a010cf9e7ae08R537 has been merged in so you can use the validation code.

:white_check_mark: odo build 1994 completed and artifacts can be found here (for commit https://github.com/redhat-developer/odo/commit/fb6f2bd9e7 by @syamgk)

:white_check_mark: odo build 2017 completed and artifacts can be found here (for commit https://github.com/redhat-developer/odo/commit/d5abadc268 by @syamgk)

:white_check_mark: odo build 2028 completed and artifacts can be found here (for commit https://github.com/redhat-developer/odo/commit/1d05f0c19d by @syamgk)

/retest

:white_check_mark: odo build 2040 completed and artifacts can be found here (for commit https://github.com/redhat-developer/odo/commit/075e6285f2 by @syamgk)

:white_check_mark: odo build 2042 completed and artifacts can be found here (for commit https://github.com/redhat-developer/odo/commit/eedd202593 by @syamgk)

does not work at all for odo app delete
$ odo app delete myapp -o json
Error: unknown shorthand flag: 'o' in -o
Usage:
  odo app delete [flags]

Examples:
  # Delete the application
  odo app delete myapp

Flags:
  -f, --force            Delete application without prompting
  -h, --help             help for delete
      --project string   Project, defaults to active project

Global Flags:
      --alsologtostderr                  log to standard error as well as files
      --log_backtrace_at traceLocation   when logging hits line file:N, emit a stack trace (default :0)
      --log_dir string                   If non-empty, write log files in this directory
      --logtostderr                      log to standard error instead of files (default false)
      --skip-connection-check            Skip cluster check
      --stderrthreshold severity         logs at or above this threshold go to stderr (default 2)
  -v, --v Level                          log level for V logs. Level varies from 0 to 9 (default 0).
      --vmodule moduleSpec               comma-separated list of pattern=N settings for file-filtered logging

 ✗  unknown shorthand flag: 'o' in -o

odo project delete still shows non json output
▶ odo project delete tkral-test -o json
This project contains the following applications, which will be deleted
 Application  fuse-rest-ht-ykzu
No services / could not get services
 Application  fuse-rest-ht-hrfi
No services / could not get services
 Application  odo-xtfm
No services / could not get services
 Application  myapp
  This application has following components that will be deleted
  component named  odo-java-sqmx
    This component has following storages which will be deleted with the component
     Storage named  mystorage  of size  1G
No services / could not get services
 ✓  Deleting project tkral-test
Deleted project : tkral-test
You are not a member of any projects. You can request a project to be created using the `odo project create <project_name>` command

▶ odo delete test -o json
 ✓  Deleting component test

it is still returning normal output

So you mean it should not print anything other than JSON formatted output in case of delete?
I guess I got confused by reading the issue

Closing this PR, will break down this to small patches and raise again


Test transaction ordering

Add tests to ensure we provide ordering for the Nitro builder requirement.
Relevant discussion starts from here: https://espresso.zulipchat.com/#narrow/stream/330967-Sequencer/topic/Builder.20API.20to.20support.20Nitro.20sequencer/near/456836223.

Pasted from Zulip:
Basically what should still result in correct txn order

leader doesn't propose transactions we've given on one of the views
leader proposes only first few of transactions we've given
leader proposes transactions we didn't give out yet (simulating a case where it received those from elsewhere)
leader doesn't propose at all
leader proposes with a bad proposal on one of the views

What we should handle with tweaks to the test

leader proposes transactions we've given out interspersed with other transactions
chain forks, with one chain proposing transactions we've given and the other not (we should give out the next batch if responding for first chain and both batches for the other)

What we can't handle

leader proposes transactions in modified order
leader skips any transactions


SOLR-15734: Add dev-docs on Solr APIs

https://issues.apache.org/jira/browse/SOLR-15734
Description
Solr's API situation generally has seen a lot of change in the last few years.  Many developers may feel unsure of the current status of various APIs and frameworks, or uncomfortable touching this part of the code.
Solution
Some documentation on how Solr "does" APIs currently and how users may write new APIs should go a long way towards making it easier for developers to feel comfortable in this part of the code.
The contents of these docs borrow from some JIRA writeups I've done previously, but have been updated significantly and rounded out a good bit to cover v1 APIs as well.
Tests
Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem.
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[x] I have created a Jira issue and added the issue ID to my pull request title.
[x] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[x] I have developed this patch against the main branch.
[ ] I have run ./gradlew check.
[ ] I have added tests for my changes.
[x] I have added documentation for the Reference Guide

Would this page benefit from a short sample API calss with annotations at the end? Or just link to a source file suitable for learning?

Good suggestion - I ended up linking to some existing files, since there's plenty of examples out there already!
Thanks all for the review, lmk if you think of anything else.


Now we can mount plugins directory for Docker (also for non-docker).

Type: feature
Description:
Since user that are using Docker image are not able to add plugins, this feature will let them mount plugins directory.
This feature is really mandatory for Docker users of this project.

@idangozlan there is a way to increase the coverage on this?


Refactor Transitions and Moves

This PR refactors Moves and Transitions according to what we have agreed on. Namely, it:

refactor transition and move iterators into a simple single class objects with their own const iterators.
includes epsilon and symbol move iterators.
updates Python binding to work with the current implementation over Transitions.
moves methods about iterating over transitions into Transitions.

Questions to resolve:

Do we need Delta::transitions_begin() (..._end()) and StatePost::moves_begin() (epsilon_moves_..., symbol_moves_...; ..._end()) methods? Currently, you have to get the Moves and Transitions classes to get begin or end iterator to moves and transitions.

@vhavlena Since you have been invested in the discussion about transitions and moves, could you have a look at how the transitions and moves were refactored (what is the current interface for them) and give your opinion on how you are satisfied with it?

It seems fine. I would rename const_iterator to ConstIterator to match the convention.

I would rename const_iterator to ConstIterator to match the convention.

For renaming custom iterators, I have created a separate issue #312. I will keep the current naming convention in this PR. We may rename all custom iterators at once later on when resolving #312.

All the issues and suggestions have been addressed. If you want to add anything more to this PR, let me know. Otherwise, when @kilohsakul reviews the code and his issues are resolved, the PR should be finished and ready to be merged.

@kilohsakul What do you think about the latest changes, moving the code handling getting iterators to symbol posts to iterate over to functions moves(), moves_epsilons() and moves_symbols()? Is there anything more you would like to change, or do you approve the PR?

PR has been rebased onto the current devel with refactored CMake. Once GAs finish, the PR will be merged.


Update stable version in repo from 1.5.1 to 1.5.3

Think about update stable version to 1.5.3
Version: stable=1.5.1 (59 days old) => latest=1.5.3 (15 days old)
Installs: stable=53 (40.46%), latest=10 (7.63%), total=131
Click to edit

published 1.6.0 to stable

published 1.6.0 to stable


do you want CI ?

I can integrate Travis CI and molecule with testing in docker for this role if you want :)
Examples of such config are in:

https://github.com/cloudalchemy/ansible-prometheus
https://github.com/cloudalchemy/ansible-grafana

Do you want it?

It was planned but I sadly lacked time to implement it.
Feel free to do the PR ;)


feat: changelog generation

Summary
This pull request adds a new script that further automates the release process with change log generation (example output). This changelog script supersedes the existing update-version script and still hands off to the publish script. Internally, the changelog script takes care of the following:

Determines the correct new version based on commit history
Generates and commits and fresh CHANGELOG.md
Updates both the root and the rome package versions
Creates and pushes an associated git tag

Note that this whole process works best if the conventional-commits specification is adhered to (and a new parser was added accordingly). If this work lands, we can optionally enable a GitHub action that fails CI if conventional-commit messages are not used.
Resolves #865
Test Plan
On main without any uncommitted changes, run:
./rome run scripts/changelog

Curious, is this only for maintaining rome itself, or will consumers also use this changelog generation?

@milesj

Curious, is this only for maintaining rome itself, or will consumers also use this changelog generation?

We discussed this a bit in the Discord. Right now just internal but this tooling definitely has a place in Rome in the future for public usage. There are some exciting points of integration such as automatically running tests to detect breaking changes and comparing module type signatures.

That sounds great.
However, the reason I ask is because the conventional commits parser allows for presets that define the commit message format. For example, I wrote my own (https://github.com/beemojs/conventional-changelog-beemo), and ESLint has its own (https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-eslint), and so do many others (https://github.com/conventional-changelog/conventional-changelog/tree/master/packages). This current implementation is hard-coded to the default spec/preset (angular). It would be nice if it supported these additional presets.
Most of this functionality is already handled by the official conventional commit/changelog packages: https://www.npmjs.com/search?q=conventional- I know Rome is trying to be dependency free, but this may be an opportunity to rely on optional peer dependencies.

@milesj agreed re: supporting various presets. The commit parser added as part of this work will parse any flavor of the conventional-commits specification, it's only the generation of the log itself that's biased towards the Angular preset right now (and only because we've been using that internally by happenstance.) It should be light-lifting to allow breaking, minor, and patch types to be customized, which should satisfy most downstream presets.

we can optionally enable a GitHub action that fails CI if conventional-commit messages are not used.

This would be great. I've never really followed any particular commit style so this would be a forcing function. I have a few other unrelated ideas on possible GitHub actions that would help us but never looking into setting anything up.


SELECTing a big integer - last number becomes 0

Hey,
I already described the problem here http://stackoverflow.com/questions/30547874/node-mysql-is-returning-a-slightly-modified-int.
I think there is a bug in the node_mysql module, because when I run the exact same query per CLI, it returns the right value.

It is literally a limitation of JavaScript itself. You have to use the  supportBigNumbers option, at least (see the readme for options at https://github.com/felixge/node-mysql/blob/master/Readme.md#connection-options).

The main problem is that JavaScript itself cannot handle numbers that big (you can test it yourself by making a script, assigning your number to a variable and then printing it). Your only option is to store those numbers as strings and we provide a couple options that help you do that in the connection options.


Compatability with interpret v0.3.0

ebm2onnx version: v1.3.0
Python version: any
Operating System: any

Description
Hello ebm2onnx team,
I recently discovered that ebm2onnx cannot cope with the recent changes of interpret v.0.3.0.
Further deatils can be also found at https://github.com/interpretml/interpret/issues/388.
The problems are more or less related to the changes of interpret to be more scikit-learn conform. This has effects on the feature_names, feautre_types and feature_groups_ attributes of the model.
See e.g. https://github.com/interpretml/ebm2onnx/blob/master/ebm2onnx/convert.py#L86.
What I Did
import ebm2onnx
from interpret.glassbox import ExplainableBoostingRegressor
from sklearn.datasets import load_diabetes

diabetes = load_diabetes(as_frame=True)
df = diabetes.frame
X = df[diabetes.feature_names]
y = df["target"]

ebm = ExplainableBoostingRegressor()
ebm = ebm.fit(X, y)
ebm2onnx.to_onnx(ebm, ebm2onnx.get_dtype_from_pandas(X))

Results in:
Traceback (most recent call last):
  File "dummy.py", line 15, in <module>
    ebm2onnx.to_onnx(ebm ,ebm2onnx.get_dtype_from_pandas(X))
  File "/opt/miniconda/lib/python3.8/site-packages/ebm2onnx/convert.py", line 86, in to_onnx
    inputs = [None for _ in model.feature_names]

yes, the changes are available in the feature/develop branch, and ready for release.
We will merge/publish very soon.

Great to hear, thanks for the update @MainRo
Will be fixed by new release.

emb2onnx v2.0.0 has just been released.


Error 404

I cant download any song after reinstalling my windows. It giving me hardcode error 404. Please help me

Please update the tool using Pip command to version 1.9.0


Joining request

Can i join this community? BitByte-TPC

If you are from IIITDM Jabalpur then you are most welcomed to join here.
If not then contact the admin.


[Enhance] Make the compression and decompression async

As a user, I want the package compression/decompression operations to be async so that it does not lock visual studio.
This is most noticeable when the solution is over 200 MB, even though its for 2-3 seconds.

Marked for v1.8


Fix output discriminator issue

Fixes https://github.com/Azure/autorest.csharp/issues/3426
Description
Setter of a property is omitted in some cases, but we should never omit the setter for a discriminator property because it causes compilation errors.
Checklist
To ensure a quick review and merge, please ensure:

[ ] The PR has a understandable title and description explaining the why and what.
[ ] The PR is opened in draft if not ready for review yet.

If opened in draft, please allocate sufficient time (24 hours) after moving out of draft for review

[ ] The branch is recent enough to not have merge conflicts upon creation.

Ready to Land?

[ ] Build is completely green

Submissions with test failures require tracking issue and approval of a CODEOWNER

[ ] At least one +1 review by a CODEOWNER
[ ] All -1 reviews are confirmed resolved by the reviewer

Override/Marking reviews stale must be discussed with CODEOWNERS first

I am good to have a separate issue to track the init/set for discriminator and let's first unblock the major issue.
So I approved this change.


dns/bind: daily dnsbl updates

Closes #1022
if there is a file "$DESTDIR/dnsbl.list" and there are no arguments, use "$DESTDIR/dnsbl.list" instead of arguments
If there are arguments, use those and overwrite the content of "$DESTDIR/dnsbl.list" with the new arguments -> cron can run dnsbl.sh without arguments, remembers the selected lists and updates the lists

I think there is only one way to deal with this: create a bind rc.conf variable with your blacklists and source that from the file to avoid any side effects

@fichtner I'm not sure if rc is the right way to go as the script is not related to bind pkg, only the script itself needs the include, not the bind config itself

I agree, but it's the best place we have short of reading the values from the config and turn it all into a PHP script

Ok, can we agree we accept this one in the short term to close this bug and we'll rewrite the script in php to get rid of this workaround?

3ee1ce7fb80b is safer. PHP has other issues. At least this keeps complexity low and defines easy points for tracing problems later on.

Cool, this was easier than I thought of, thanks 👍


Fix deprecation warnings in CI workflows

We are getting deprecation warnings in our CI workflows. This cleans them up.

Hmmm, looks like we can’t fix the other warnings yet; the official AWS actions don’t have a new version with the right Node.js support yet: https://github.com/aws-actions/configure-aws-credentials/issues/489


Inference using tfjs with a custom trained YOLOv3 model

Model trained with custom data (using train.py) will introduce two extra inputs. When I use tfjs to do inference, the error Error when checking model : the Array of Tensors that you are passing to your model is not the size the the model expected. Expected to see 3 Tensor(s), but instead got 1 Tensors(s). shows.

When I use the pretrained yolov3 model (yolo.h5 generated via convert.py). It only has one input and two outputs, and I can get tfjs working well with it.

Is it possible to deploy the model with same architecture as the pretrained yolo.h5 ?

I have trained a custom Yolo-V3-tiny model with 2 classes (final filter size is 21).  My custom darknet model works well in darknet, but when converted to keras it no longer detects (like reported by others here).
I dug into it more, and found that the final stage of the converted keras model had additional weights....21 extra to be precise.  Below is from the model.summary()....
        stage                 output     weights              from

conv2d_9 (Conv2D)    (-,-,-, 21)      10773      lky_re_lu_8[0][0]     <<   26 x 26 x 21...expects 10,752
conv2d_12 (Conv2D)   (-,-,-, 21)      5397       lky_re_lu_10[0][0]    <<  13 x 13 x 21...expects 5,376
NOTE the covd2d_9 layer should have 10,752 weights, because  wt = input * size1 * size2 * output  => 512 x 1 x 1 x 21.  The converted version has 10,773 because I believe it did 513 x 1 x 1 x 21.....Which looks like to be a bug?  Similarly the math for the 13 x13 output stage (conv2d_12) is 256 x 1 x 1 x 21 = 5376.  And the converted was 257 x 1 x 1 x 21 = 5397.  Both are off by 21, which is one EXTRA INPUT.  Why?
I am digging into the code to see what caused the bug and there is quite a bit of learning curve, I suspect a side effect with the vector math somewhere, and I hope somebody smarter can figure this out.

Following this! This seems like a very serious point

I too have the same problem, yolo weights predicts result but converted keras model does not predict any result. Any solution?


edit text for tweet and discord post

I am working on fixing the linting error

@diwash007 I suppose you should have a look at @thenishantsapkota's PR first.


../../FlutterDev/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_form_builder-7.2.1/lib/src/fields/for m_builder_date_time_picker.dart:355:7: Error: No named parameter with the name 'anchorPoint'.       anchorPoint: widget.anchorPoint,

First time  I Fixed This issues:
../../FlutterDev/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_form_builder-7.2.1/lib/src/fields/for
m_builder_date_time_picker.dart:355:7: Error: No named parameter with the name 'anchorPoint'.
anchorPoint: widget.anchorPoint,
^^^^^^^^^^^
../../FlutterDev/flutter/packages/flutter/lib/src/material/date_picker.dart:133:19: Context: Found this
candidate, but the arguments don't match.
Future<DateTime?> showDatePicker({
^^^^^^^^^^^^^^
../../FlutterDev/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_form_builder-7.2.1/lib/src/fields/for
m_builder_date_time_picker.dart:373:7: Error: No named parameter with the name 'anchorPoint'.
anchorPoint: widget.anchorPoint,
^^^^^^^^^^^
../../FlutterDev/flutter/packages/flutter/lib/src/material/time_picker.dart:2413:20: Context: Found this
candidate, but the arguments don't match.
Future<TimeOfDay?> showTimePicker({
I cleaned my app then rerun it but no thing is changed
This is my question on stack overflow:
https://stackoverflow.com/questions/72515666/flutter-form-builder-with-date-picker-no-named-parameter-with-the-name-anchorp

Faced the same issue. Did what Elvin suggested and it worked. But I think this is a temporary fix.

Duplicate of another one. Please check y suggestion or from others here:
https://github.com/danvick/flutter_form_builder/issues/1028#issuecomment-1151271662
Feel free to re-open if it is a different scenario.


🐛 BUG:

Which Cloudflare product(s) does this pertain to?
KV, Wrangler
What version of Wrangler are you using?
2.12.3
What operating system are you using?
Linux
Describe the Bug
wrangler kv:key put does not work as expected when using --path with --metadata commandline options.
Meaning of "as expected": the same bytes can not be read with kv:key get, that were previously put.
Simple way to test:
This works: the same file can be get, which were put:
md5 original.png
81a3478c5f2b12823f3ff0253c3388e7
wrangler kv:key put --binding=FILES kvimage.png --path=original.png
wrangler kv:key get --binding=FILES kvimage.png > copy.png
md5 copy.png
81a3478c5f2b12823f3ff0253c3388e7
This does NOT work, md5 does not match, the bytes are different:
md5 original.png
81a3478c5f2b12823f3ff0253c3388e7
wrangler kv:key put --binding=FILES kvimage.png --path=original.png --metadata='{"contentType":"image/png"}'
wrangler kv:key get --binding=FILES kvimage.png > copy.png
md5 copy.png
40621887293ab018c535120fe0b6bf92
Looking code:
I think the problem is that wrangler is putting the Buffer data into FormData, to be sent to KV. And this is a wrong type of data to be added into FormData.
--path file is read with readFileSyncToBuffer, which returns node-Buffer
https://github.com/cloudflare/workers-sdk/blob/main/packages/wrangler/src/kv/index.ts#L236
This is given to function putKVKeyValue
https://github.com/cloudflare/workers-sdk/blob/main/packages/wrangler/src/kv/helpers.ts#L203
which tries to append the Buffer into undici FormData object.
https://github.com/cloudflare/workers-sdk/blob/main/packages/wrangler/src/kv/helpers.ts#L193
undici FormData append expects value to be eg. Blob or File, but receives Buffer. So Buffer is converted to string.
https://github.com/nodejs/undici/blob/main/types/formdata.d.ts#L27

The cleanest way to fix this, is to send metadata in PUT-headers: KV can hold only a very small size of metadata-data anyway, so this would not brake anything on storing data.
This also enables the value always to be sent as PUT-body. Which also might help to deliver filedata as ReadStream on PUT-body, instead of potentially 25MB of Buffer in memory.

Can verify this is happening. Had me utterly stumped for a long while.

Linking the culprit with a specific commit hash so it doesn't move around when the file is modified :) https://github.com/cloudflare/workers-sdk/blob/9a46e03f013cc6f1e2d38d47f9bf002626b6bd95/packages/wrangler/src/kv/helpers.ts#L199-L207
I think we can get away with checking if the type is a Buffer, and if so, convert it? Something like
function asFormData(fields: Record<string, unknown>): FormData {
	const formData = new FormData();

	for (let [name, value] of Object.entries(fields)) {
                if (Buffer.isBuffer(value)) {
                    value = new Blob([value]);
                }
		formData.append(name, value);
	}

	return formData;
}

Maybe there's a more elegant way of doing it, but I'll open a PR with this change to at least get things moving in the right direction.


"Add folder to workspace" prompt duplicates itself if you add and then remove a folder from the workspace repeatedly

VSCode Version: 1.43.0
OS Version: Windows 10

Steps to Reproduce:

Add a folder to the workspace
Remove the folder from the workspace, so that there are no folders in the workspace.
Add another folder to the workspace
Remove that folder from the workspace
Repeat

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

@RM-Eric good catch. Thanks for filling this!


Autocrafting efficiency

Issue description:
Autocrafting could be more efficient when a recipe has a dependency on multiples of another autocrafted component.  My use case is with Mekanism induction cells.  The basic tier requires 4 energy tablets.  These get crafted one after the other rather than 4 simultaneously.  If I manually request 4 tablets, they get made simultaneously.
What happens:
Multiple identical components of a crafting recipe get crafted sequentially rather than simultaneously.
What you expected to happen:
They would be crafted simultaneously.
Steps to reproduce:

set up the recipes for a mekanism basic induction cell
request one
the energy tablets get made one after the other rather than simultaneously
...

Version (Make sure you are on the latest version before reporting):

Minecraft: 1.10.2
Forge: <IP_ADDRESS>0
Refined Storage: 1.1.3

Does this issue occur on a server? [yes/no]
yes
If a (crash)log is relevant for this issue, link it here:
[pastebin/gist/etc link here]

Could you share a screenshot of your setup? Cause there shouldn't be a difference. The crafting speed is based upon the amount of speed upgrades in a the crafter holding the pattern.

Wow, so much awesome! You guys are great ...

Yeah, 1.2 has quite the feature set :D

I'll check it out in single player, the server I'm on probably won't get this update for a while


CODE_DESERIALIZATION_ERROR while running "dove run"

While trying to run "dove run" with Dove 1.3.0, I get:
➜  taohe git:(master) ✗ dove run --file immutable
Execution failed with unexpected error CODE_DESERIALIZATION_ERROR

This used to work with 1.2.8.
You can use https://github.com/taoheorg/taohe for testing (master supports Dove 1.3.0).
EDIT: If you are using TaoHe for testing, it's probably noteworthy that dove run --file dummy does not produce any output, but instead terminates silently.

This is fixed now, closing :slightly_smiling_face:
However, it seems I misunderstood the new syntax: to me, it seems that the syntax could be simpler, account_address from Dove.toml could be used automatically instead of "_" if one signer is required.


How to get output video?

I seeing the example to crop video as the link below
https://codesandbox.io/s/react-easy-crop-for-videos-lfhme
However, I don't know How to get output video?
Any ideal?
Thanks.

I don't think this is possible to do it in the browser. You need to do this server side with something like Ffmpeg.


Add smart contract rent to the fees table

Problem
The fees table in docs currently does not have contract rent noted.
Solution
Add smart contract rent.
Alternatives
No response

This will be added when progress has been made on this topic the future


Scheduled Refresh Dataset Table Timings

The articles don't discuss how a scheduled refresh for an import on SQL Server is executed. I noticed that some of my dataset tables with a handful of records return newly processed information before the processing is complete for large fact tables. Analysis Services preforms a swap of the data models after processing is complete. Is the scheduled refresh in Power BI refreshing each table independently and not inline with the way Analysis Services swaps the complete data model? My users are confused as to why the refresh timestamp defined by the (DateTime.LocalNow()) function is showing a new date if the records for their sales transactions are not yet available.  Can you confirm in documentation or report a bug to the product team?

Hi @Saltzmea , You've reached the documentation team. I am not sure what documents you are referring to, but in any event this sounds more like a support request or product question than documentation feedback. I suggest you try asking your question in the Power BI Community, or, if you think this is erroneous behavior, file a bug on the Power BI support page.


release 1.5.2 failed

a github release was created, but no maven central artifacts are visible
https://search.maven.org/search?q=g:org.camunda.bpm.extension.batch AND a:camunda-bpm-custom-batch-core AND v:1.5.2

Rin, can you check, please?

Hi @jangalinski -- Thanks for opening this issue! I tried to re-run the Action on the hope that it would complete/fill in the missing information, but it's currently failing for me. @Langleu, is there a way I can resolve this in order to help Jan get this release staged so I can publish on Maven Central? TYSM!

Hi again @jangalinski -- I went ahead and released this on Sonatype and if you could let me know if the artifact is available, that would be great! It can take a few hours and up to a few days for artifacts to be visible, but I hope it won't take too long! :) If that doesn't work, please do let me know and we can troubleshoot further for sure!

Just a question, Rin. Is there a reason, why the Sonatype isn't automated?

Hi @zambrovski! Sonatype isn't automated for a few reasons, firstly for security. Second, if there were ever faulty releases, they would permanently be on Maven central since every object is immutable. That being said, I am happy to propose looking into this further to the team, and will take this feedback into consideration as we continue to shape the future of the Community Hub! :)

Hm. Don't get it. If you provide access to the repo maintainer, who can click on release button and this crates a release and then you ask the same person for ok? So there is no real check neither for security nor for the content, since no one would check the intermediate release on sonatype (due to lack of permissions).
So why not simplifying this step and binding the release publishing to release production? In the Open source world - a wrong release is not a problem if that is replaced fast... having manual steps - you slow down the release process... just my 5 cents for this...
If versioning scheme is maintained, everyone would go for the latest patch release ...

Hi @jangalinski -- I just checked https://search.maven.org/search?q=g:org.camunda.bpm.extension.batch%20AND%20a:camunda-bpm-custom-batch-core%20AND%20v:1.5.2 and the artifact appears to be available now! Can you confirm that's working as intended? Thank you kindly!

Thanks celanthe, can confirm it is available on central. And btw: this is not my release, @pschalk triggered it ... I just found out that it is not available on central.
I do not really care how we solve this problem, but we have a "two phase commit" kinda problem here.   Github release is done, the right column features a prominent label "latest release: 1.5.2". The "release issue" is closed ... the code is tagged ... but I cannot use the lib from central (unless I have very keen eyes and check the maven central badge on the readme to see that 1.5.2 is in fact not on central). And then I as the author (or just someone interested in using the lib) have to ask. And wait.
So we need a "happy path" where when nothing special happens, I can just assume that gh-release and sonatype release happen at the same time, and that due to cache/index updates it just may take a few hours until I see the lib on central.
If this is automated or using some "high prio" user task on your side ... open for discussion.


Android background

Per documentation, android Foreground Services are not affected by doze mode. But even you use socket client inside such service when you press the power button and turn off the charging, you will get SocketTimeoutException because pong is not received on time. Can we create a stable socket connection in any device condition using this library?

Can you rephrase this as a request?

To be honest, I don't know which category is better to relate this issue. I've seen other issues before, where the implementation was in the background service. And in the response, it was said that the connection is lost because of the platform limitations, and you need to use the foreground service to circumvent these restrictions. But after trying such an implementation, the result remained the same. And I would like to understand whether it is possible to create a stable socket connection in any device condition?

Yeah, I understand this. I asked a question on StackOverflow, but I did not get any answers to it. So, although the question doesn't directly apply to the library, I decided to clarify this point here, because, at the time of development, you may have received an answer to this question. I apologize for the inconvenience, if delivered them.

Link to the StackOverflow issue?

Which version of Android is this on for example?

https://stackoverflow.com/questions/51133783/socket-connection-in-background

I think this is more of an Android question than an OkHttp question. I'm interested to find out if there is a way to keep the web socket open, but I don't think theres any action we can take here.

Thank you for your response.

So I finished my research, and I can say that the problem belongs to Android. The ways to solve it can be seen in the answer to the StackOverflow on the same link.
Best regards,
Vyacheslav


Fix hot reloading for read_asset_bytes

Objective
Fixes #6780
Solution

record the asset path of each watched file
call AssetIo::watch_for_changes in LoadContext::read_asset_bytes

Changelog
Fixed

fixed hot reloading for LoadContext::read_asset_bytes

Changed

AssetIo::watch_path_for_changes allows watched path and path to reload to differ

Migration Guide

for custom AssetIos, differentiate paths to watch and asset paths to reload as a consequence

bors try

Awesome thank you

bors try

bors r+


figure error

Description
figure error
(Optional:) Please add any files, screenshots, or other information here.
No response
(Required) What is this issue most closely related to? Select one.
Formula
Internal issue ID
274a7ea8-b735-42b2-bc65-86f93deb0d5c
Paper URL
https://arxiv.org/html/2401.08815v1
Browser
Chrome/<IP_ADDRESS>
Device Type
Desktop

Is the error related to figures that are laid out using epic and/or figures that include tikzsymbols?


chore: refactor ini signatures to accept &str to reduce cloning

This commit changes the signatures of several functions in the ini_config module to accept slices of &str or String, rather than just Vec, so that we don't need to do so much cloning before calling these functions.  Also removes calls to clone in several call sites.

This one has been rebased and then I added a commit that implements Kenny's suggestion.


Hugchat skill is not working for me anymore?

Hugchat skill was working perfect for me, but today I noticed, that it is not working anymore? Ovos is always answering with "error".
In the ovos core log I found this error line:
2024-08-21 12:30:16.041 - skill-ovos-fallback-hugchat.femelo - ERROR - ChatBot.query() got an unexpected keyword argument 'web_search'

Thanks for the report, @Dante1975X. The Hugging Chat API is constantly changing, I will try to solve this asap.

The problem, as expected, was on HugChat's side. Can you please uninstall the corresponding hugchat, the solver plugin and the skill and reinstall the skill?
python3 -m pip uninstall  --yes hugchat ovos-solver-hugchat-persona-plugin skill-ovos-fallback-hugchat

python3 -m pip install git+https://github.com/femelo/skill-ovos-fallback-hugchat.git

Solved by the PR #1 for the corresponding plugin.


Jitter correction makes some warning message relating to rebin

@kylechampley I added some jitter correction algorithm with leapct, and I can see some warning message from leapct as like below. I wonder it does not bring any side effect into all reconstruction action. If I use uneven angle space then it is normal of this warning message?

Below is my jitter correction algorithm flow.

estimate angle deviation from 0 to 360 each degree projection images with phase correlation.
update angle table with this deviation into leapct class's angle table memory.
FDK call for full reconstruction.
below is my result between corrected and not-corrected.

You must be using either rebin_parallel or estimate_tilt right?  I hope you are not rebinning to cone-parallel coordinate because I would only recommend this if you are doing medical CT.  Anyway, this is just a warning, not an error.  The code that does the interpolation uses Lagrange polynomial interpolation.  I think the default is to use a 6th order polynomial.  But if your projection angles are non-equi-spaced, I just use linear interpolation.  I did this because it was too much of a pain to figure out how to do this efficiently with higher order polynomials.  The overall impact is that linear interpolation gives a result that is not as sharp.

Current just warning is not critical for my application. I will keep it. Thanks so much for explanation.


refactor: structure overhaul

This PR splits the Nitro codebase into logical scopes separated by subpath exports.

nitropack/cli: Nitro CLI. Will be used for standalone zero dep CLI package in the future
nitropack/core: Main utilities exposed for programmatic usage, dev and build + app (same as nitropack for now)
nitropack/runtime: Core server runtime logic (see notes below)
nitropack/types: All types unified in a single place (see notes below)
nitropack/config: Config type helper (loader, defaults, and normalizers live in core)
nitropack/kit: Possibly reusable utilities for module and preset authoring as well as external integrations
nitropack/presets:  deployment presets (runtime, config, types) (#2446)
nitropack/package.json: non-bundled subpath for getting version

[!NOTE]
This PR introduces lots of changes to the current 2.x codebase in order to make sure we can keep supporting Nitro 2.x for a longer term in parallel to Nitro 3.x. A lot of thoughts have been put in to make sure we don't intentionally break any common or documented usage. There is still a chance that some changes introduce regressions. We will keep investigating to find and resolve them as much as possible via Nitro nightly channel. If you spotted any, please feel free to open an issue and describe the case 🙏🏼

What happened to types?
Currently, types are split in several places from core, bundler, and runtime and exported from several places. Now they are unified and accessible from (type-only) nitropack/types subpath.

[!NOTE]
This change is likely break-in usages augmenting Nitro types from "nitropack" subpath. This will be addressed in a subsequent PR after better testing via a backward-compatible polyfill.

What happened to the core?
Externally, almost nothing. Exactly the same exports are preserved for compatibility. Internally, some important major refactors happened:

Config loader and resolvers moved to modular core/config
Core logic (nitro.ts) split into scan utils and config resolvers
Builder utils split into modular units for better maintenance

What happened to runtime?
One of the messy parts of the current code structure was runtime. It was:

Exposing all internal utils
Exposing userland utils (for auto imports)
Exposing preset internal utils
Available as #internal/nitro or #internal/nitro/* for import

To add to the complexity, the virtual files were ALSO exposed in the same #internal/nitro/virtual namespace.
The new structure makes it much cleaner:

nitropack/runtime: Exposing userland utils (same as auto imports)
nitropack/runtime/internal/*: Exposing internal utils. Users and frameworks should NEVER EVER use them they will be soon protected as well to prevent wrongly importing from this namespace this is because we need to improve nitro internal implementation without imposing breaking changes
New virtual (+internal) imports:

#nitro-internal-pollyfills
#nitro-internal-virtual/*

Since this PR is landing for Nitro 2.x, to avoid breaking changes in projects and frameworks that for any reason had to use #internal/nitro, there is a compatibility layer with minimal known usages (mainly from Nuxt codebase), they are maintained in src/runtime/_compat.
What is the new kit?
The new nitropack/kit exports common but shared utils + define helpers. More will be added in the next steps

defineNitroPreset and defineNitroModule
writeFile, isDirectory, prettyPath, resolveNitroPath

(this PR is likely making unsen regrssions as mentioned above and merge is intended to identify them end-to-end and fix in nightly channel progressively)


Pymca-like display of legends?

Users would like to see legends like in PyMCA, under Plot1D without the need to click on 'options' then 'legends', and with a compact view.

If that can be called programmatically I guess it is the instantiating program the one that has to take the responsibility to show the legends dockwidget.

@mguijarr
Plot1D behaves exactly like PyMca so you users should be used to it.

@vallsv We appreciate a lot silx, and we are already doing integration with the toolkit... However we
are also at the forefront of remarks from users, and this issue (and the previous one I added) is an
attempt to tell you what users are asking to us. Please don't blame the messenger.
So, about legends display, I took a picture of pymca from the web and you can see the compact
representation of the legend below the graph (you can see Data, Fit, Continuum, etc) :

I think we can agree the Plot1D widget at the moment displays legends very differently ?
@sole: maybe behaviour is the same, but it does not look the same and I report to you our users prefer the pymca look and feel. Don't forget our users are your users too ;)

That behavior was lost when dropping PyQwt. That means something like four years ago!!!
Current silx behavior is the same as PyMca.
The only thing silx is not respecting concerning the legends it is what I have reflected in issue #2011

This is how it looks now in PyMca.

The Qwt look and feel was nice when having a few curves. However, when having many curves, the legends were eating most of the plot space. Current way is safer in that sense besides paving the way to future improvements like replacing the contents of the legends widget by a tree widget with access to all the properties of the curves (as it is done with the 3D objects in the silx 3D visualization widgets)

Then this issue is about embedding legends in the plot? Is that a duplication with #1447?

@mguijarr thanks for the feedback. We do need feedback from users.
I think we all first misunderstood as the legend display in silx comes from the one in the current version of PyMca... the screenshot makes it clear.
Anyway, there is a need for a compact legend display (2nd issue on the subject with #1447)

+1 for as an alternative way to display the legend
I believe it is a natural to expect the legend to be on the plot canvas; think about how most plots are displayed in publications. This would also help when the plot is saved to file.


How to set allowUnfree/allowUnsupportedSystem

Hi all, sorry for this noob question but I've been bashing my head at this for a while.
When wanting to add specialArgs to the system definition in flake.nix I'm getting errors that something breaks internally in x1e-nixos-config, that I think is trivial to someone used to NixOS.
Could you help me understand my mistake? Maybe this extension is worth adding to examples/flake-based-config/flake.nix?
Thank you for this awesome repo!
Example system:
        # Lenovo Yoga Slim 7x laptop
        yoga-x7 = nixpkgs.lib.nixosSystem {
          specialArgs = {
            inherit inputs;
            pkgs = import nixpkgs {
              system = "aarch64-linux";
              config.allowUnfree = true;
              config.allowUnsupportedSystem = true;
            };
          };

          modules = [
            ./hosts/laptop-yoga-7x/configuration.nix
            ./modules/common.nix

            home-manager.nixosModules.home-manager
            {
              home-manager.extraSpecialArgs = {
                inherit inputs;
              };
              home-manager.useGlobalPkgs = true;
              home-manager.useUserPackages = true;
              home-manager.users.emifre = import ./home.nix;
            }

            # Hardware configuration
            x1e-nixos-config.nixosModules.x1e
            (
              { ... }:
              {
                networking.hostName = "emifre-yoga-7x-nixos";
                hardware.deviceTree.name = "qcom/x1e80100-lenovo-yoga-slim7x.dtb";

                nixpkgs.pkgs = nixpkgs.legacyPackages.aarch64-linux;

                nix = {
                  channel.enable = false;
                };
              }
            )
          ];
        };

Give the error:
error:
       … while calling the 'head' builtin
         at /nix/store/a6jqddv0qxcy62nl61ak946mhi1bajh9-source/lib/attrsets.nix:1574:11:
         1573|         || pred here (elemAt values 1) (head values) then
         1574|           head values
             |           ^
         1575|         else

       … while evaluating the attribute 'value'
         at /nix/store/a6jqddv0qxcy62nl61ak946mhi1bajh9-source/lib/modules.nix:816:9:
          815|     in warnDeprecation opt //
          816|       { value = addErrorContext "while evaluating the option `${showOption loc}':" value;
             |         ^
          817|         inherit (res.defsFinal') highestPrio;

       … while evaluating the option `system.build.toplevel':

       … while evaluating definitions from `/nix/store/a6jqddv0qxcy62nl61ak946mhi1bajh9-source/nixos/modules/system/activation/top-level.nix':

       … while evaluating the option `assertions':

       … while evaluating definitions from `/nix/store/a6jqddv0qxcy62nl61ak946mhi1bajh9-source/nixos/modules/system/boot/kernel.nix':

       … while evaluating the option `boot.kernelPackages':

       … while evaluating definitions from `/nix/store/i0gzxv5wix04rpap5pyc4dkzr313nzri-source/modules/x1e80100.nix':

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: attribute 'x1e80100-linux' missing
       at /nix/store/i0gzxv5wix04rpap5pyc4dkzr313nzri-source/modules/x1e80100.nix:48:25:
           47|
           48|   boot.kernelPackages = pkgs.x1e80100-linux;
             |                         ^
           49| }

I think setting specialArgs.pkgs like that is not something that should be done, it's not intended to work, and in this case it's breaking things because the overlays from this repo cannot get applied to it. The module in this repo sets nixpkgs.overlays. This is important because among other things this is what adds the kernel package to the package set.
You are also setting nixpkgs.pkgs, but now to a different nixpkgs instance that does not have your desired config options set.

I think the most elegant solution here would be for you to set your desired config options using nixpkgs.config, something like this:
{
  networking.hostName = "emifre-yoga-7x-nixos";

  nixpkgs.config = {
    allowUnfree = true;
    allowUnsupportedSystem = true;
  };
  nixpkgs.localSystem.system = "aarch64-linux";

  nix = {
    channel.enable = false;
  };
}

Make sure to remove the assignments for both specialArgs.pkgs and nixpkgs.pkgs. (Because if nixpkgs.pkgs is set, then nixpkgs.config is ignored, as per the documentation.)
Please let me know if this solution worked :)

Oh so that was it, the error seemed like it pointed me towards something being overwritten in your additions.
Now that you show it, it makes perfect sense - thank you! :rocket:


add support for gcc byteoder defines to windows platform

needed to unblock https://github.com/tensorflow/tensorflow/pull/5450

Can one of the admins verify this patch?

@tensorflow-jenkins test this please.

@tensorflow-jenkins test this please.

CPU failures known issues.


Exception when subscribing to event

Describe the bug
When subscribing to Changed event occurs error.
To Reproduce
Steps to reproduce the behavior:

Run this code on net framework

using System;
using System.Collections;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;
using System.Runtime.Serialization.Formatters;
using CoreRemoting;
using CoreRemoting.DependencyInjection;
using CoreRemoting.Serialization.Binary;

namespace ProgramTest
{
    public class Program
    {
        private static void Main(string[] args)
        {
            try
            {
                //RegisterChannel(7801);
                //RegisterSingletonSAOType(typeof(SayHelloService));
                //var proxy = CreateTypeInstance<ISayHelloService>("localhost",
                //    7801);
                //proxy.Changed += Subtype_Changed;

                var server = new RemotingServer(new ServerConfig()
                {
                    HostName = "localhost",
                    NetworkPort = 7801,
                    RegisterServicesAction = container =>
                    {
                        // Make SayHelloService class available for RPC calls from clients
                        container.RegisterService<ISayHelloService, SayHelloService>(ServiceLifetime.Singleton);
                    },
                    Serializer = new BinarySerializerAdapter()
                });
                server.Error += Server_Error;
                server.Start();

                var client = new RemotingClient(new ClientConfig
                {
                    ServerHostName = "localhost",
                    ServerPort = 7801,
                    Serializer = new BinarySerializerAdapter()
                });

                client.Connect();

                // Create a proxy of the remote service, which behaves almost like a regular local object
                var proxy = client.CreateProxy<ISayHelloService>();
                proxy.Changed += Subtype_Changed;
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex);
            }
        }

        private static void Subtype_Changed(object sender)
        {
            throw new NotImplementedException();
        }

        private static void Server_Error(object sender, Exception e)
        {
            Console.WriteLine(e);
        }

        public static void RegisterChannel(int channelPort)
        {
            BinaryServerFormatterSinkProvider provider = new BinaryServerFormatterSinkProvider();
            provider.TypeFilterLevel = TypeFilterLevel.Full;
            IDictionary props = new Hashtable();
            props["port"] = channelPort;
            props["name"] = "My-TcpChanel";
            props["machineName"] = Environment.MachineName;
            ChannelServices.RegisterChannel(new TcpChannel(props, new BinaryClientFormatterSinkProvider(), provider),
                false);
        }

        public static void RegisterSingletonSAOType(Type type)
        {
            RemotingConfiguration.RegisterWellKnownServiceType(type, "MyRemoteHost/I" + type.Name,
                WellKnownObjectMode.Singleton);
        }

        public static T CreateTypeInstance<T>(string computer, int port)
        {
            return (T)Activator.GetObject(typeof(T),
                "tcp://" + computer + ":" + port + "/MyRemoteHost/" + typeof(T).Name);
        }
    }

    public class SayHelloService : MarshalByRefObject, ISayHelloService
    {
        public event ServerEventHandler Changed;
    }

    public interface ISayHelloService
    {
        event ServerEventHandler Changed;
    }

    public delegate void ServerEventHandler(object sender);
}

Expected behavior
Successful subscribe to Changed event.
Additional notes
In commented code you can check that classic Remoting works as expected. Version of CoreRemoting is 1.1.14

me too!

Support for custom event delegate types added with commit https://github.com/theRainbird/CoreRemoting/commit/dcd24275a7928e5a9ad2e88c41a5fb6ab886a903.
Subscribing the event will work as expected.
But there is a limitation when firing the event. Setting the service instance as sender parameter will fail.
It is not possible to pass a service as proxy to a remote delegate.

ОК. It works now


Redo isort

Now leaves first party imports at the bottom.

These kind of things should be merged ASAP, or they'll become inconsistent in 2 seconds. I doubt we have code that requires a strict import order somewhere.

Give me a sec, I'll resolve the conflicts and update the PR


Add OWNERS for each sub-project

The OWNERS are admin maintainers who can update/delete sub-project and create security advisories.
See the definition of roles: Repository roles for an organization
See example, https://github.com/oras-project/oras/blob/main/OWNERS.md

As clarified in another issue: CODWOWNERS and OWNERS are different.

CODEOWNERS are clearly defined here https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
OWNERS means people has the Admin role, as defined here https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/repository-roles-for-an-organization#repository-roles-for-organizations.

OWNERS is just an arbitrary file name. Maintainers can have both Maintain and Admin roles. In this case, there is no need to create another file of OWNERS.  We can update existing MAINTAINERS with the association of repository roles.

Closing this one as per the discussion above. We don't need additional file for this information.


#815 - Over calculation of columns widths can cause different width columns

Foundation seems to over-calculate the total of a row by $global-gutter, which leaves the client having to resizing the columns
Instead of
               container width
               ---------------
               No of columns

it should calculate
               container width - gutter width
               ------------------------------
                      No of columns

as there is an additional half gutter at each end of the row.
eg:
<row>
     <columns small="2">...</columns>
     <columns small="4">...</columns>
     <columns small="6">...</columns>
</row>

                     | half | half |      | half | half |
       |gutter|column|gutter|gutter|column|gutter|gutter|column|gutter|
before |  16  |80.66 |   8  |   8  |177.33|   8  |   8  |  274 |  16  | = 596
after  |  16  |  78  |   8  |   8  |  172 |   8  |   8  |  266 |  16  | = 580

This might depend on the inky markup / structure.
Can you improve the commit title? Only the issue number is not sufficient in my opinion.