[WIP - ZF3] Refactored SM

Hi everyone :),
Until we have proper split of components, let me submit a refactored service manager. There are a few features that I have not completley backported (proxy and delegators). As all my other refactors, this emphasize on performance, and I've tested it carefully with BlackFire.
The main changes is a change of interfaces: now everything is a factory, and each factory is callable, so this removes all the needed check against FactoryInterface or callable.
Furthermore, there is no longer concept of invokables: invokables are implemented as a built-in factory:
return [
   'service_manager' => [
       'factories' => [
             MyInvokable::class => InvokableFactory::class
       ]
  ]
];

In one of my previous idea, I've introduced the concept of "abstract_factories_map". In this refacotr, I've been able to remove this additional concept while keeping the idea of being able to map multiple class names to the same factory. This is make possible because the interface of a factory now has the requested class name as second parameter.
Finally, this introduce a simplification to plugin manager, and remove the need of calling "getServiceLocator". While using ZF2 extensively, I've realized that, in a factory of a plugin maanger, I nearly never need to fetch other deendencies from this plugin manager, but rather calling dependencies from the main service locator. This refactor therefore changes the context of the factory in a plugin manager.
In ZF2, if you fetched a service from a plugin manager, you had to call "getServiceLocator" to retrieve the main service locator. In this refactor, the service locator is actually the main service locator.
Finally (bis), this removes aliases from the main service manager for performance reasons. Now that we have ::class, the only reason to use alaises is for very specific plugin managers, like view plugin managers or controller plugin managers. Therefore, I've introduced an addditional, more specialized plugin manager called "AliasesPluginMAnager", that brings back the aliases.
This make the component MUCH MUCH more efficient (tbh I think there is no other way to make it faster while preserving all features), and more coherent, especially when it comes to plugin maangers.

tbh I think there is no other way to make it faster while preserving all features

Actually, there is, and even by maintaining the previous feature-set, IMO.
Yes, I'm still thinking about codegen here.

Do you mean generating optimized factories that unroll the code? Yes, that's something I've thought about too ;)... And should not be too hard!

Yes, I'd rather write an immutable service manager implementation that just skips all the method calls wherever possible (shared services) and inlines any non-shared service instantiation logic.

I've already removed nearly all mutable method calls. I'm even considering remove the configure method and being able to configure the SM only in constructor

This is make possible because the interface of a factory now has the requested class name as second parameter.

That is already the case in the current implementation when using an invokable class as factory :wink:

What do you mean? What the new implementation allows is being able to pass different service names to same factory:
return [
    'service_manager' => [
        'factories' => [
               MyService1::class => MyFactory::class,
               MyService2::class => MyFactory::class
        ]
    ]
];

This is useful when you have hard-dependencies for your object, but that the construction is similar. Previously it needed an abstract factory, which is highly inefficient. Now, you can have a simple factory and map multiple services to it. As far as I know, it is not possible currently.

No tests? ;-)
Can you explain why the abstract factories shall be removed? The factory it self was not very inefficient, depending on what you did in the "canCreateServiceWithName". Is it the code that has to figure out the call to the abstract factory?

Tests will come :).
Regarding abstract factories, the main problem comes from the fact that the process of creating object through abstract factories comes at the end of the process, after the "fast paths". If you have only 6 or 7 abstract factories, it will need to iterate through them all. Even if that's pretty fast, you must always make sure that "canCreateServiceWithName" is highly optimized.
However, I've realized that one of the use case of abstract factories is actually create multiple services that are known in advance, but follow the same creation pattern. For instance in my code I have 7 services that are created exactly the same (I have just made 7 services to have smaller services). Currently, I'm forced to create 7 different factories, OR create an abstract factory. With this new approach, because you receive the class name into the factory, you can use this config:
return [
    'service_manager' => [
         'factories' => [
              Service1::class => MyFactory::class,
              Service2::class => MyFactory::class
         ]
    ]
];

The factory looks like this:
class MyFactory implements FactoryInterface
{
    public function __invoke(ServiceLocatorInterface $sl, $className, array $options = [])
    {
           $dependency1 = $sl->get(MyDependency::class);
           return new $className($dependency1);
    }
}

Abstract factories are still here, and must be reserved for creating services that you do not know in advance.

I have added back initializers and have fixed the delegators, that now work as expected. This new implementation now have nearly feature-parity, while being substantially faster and being 4 times smaller in term of code size :D.

I can remember a discussion where somebody suggested to remove the initializers since they are a performance bottleneck. initializers can be replaced by a delegator factory? So you don't have to loop over all initializers on very get call.  But that might also be up to the users of the servicemanager...

While I don't like initializers, there are a few places where they are useful: injecting an evm by implementing EventManagerAwereInterface and injecting a service locator using ServicelocatorAwareInterfacd.
While you can inject them yourself explicitly, this is annoying fro those ones. We should discourage using initializers in general, but some use cases are hard to replace without that.
Also, if we manage to compile the SM, performance cost of initialized will be 0

What do you mean? What the new implementation allows is being able to pass different service names to same factory

I know and that is already possible in the current version of ZF2:
<?php

namespace MyNS\Factory\View\Helper;

use MyNS\Service\Foo;
use Zend\ServiceManager\ServiceLocatorInterface;

class FooFactory
{
    /**
     * @param ServiceLocatorInterface $serviceLocator
     * @param string                  $canonicalName
     * @param string                  $requestedName
     */
    public function __invoke(ServiceLocatorInterface $serviceLocator, $canonicalName, $requestedName)
    {
        // Do something
    }
}

Just a note that it is not a new feature, but an already existing one.

Hmm i didn't know that. It seems
That the service locator now give the name even for factory, but as this is not in the interface, I more consider that as a hack :p.

it is a hack, to be able to use closures in your config :-)

I more consider that as a hack :p.

Tell that to @weierophinney :wink:
http://blog.alejandrocelaya.com/2014/10/09/advanced-usage-of-service-manager-in-zend-framework-2/#disqus_thread

This PR just enforces this right into the interface :). At this point it cannot be changed in ZF2 because of BC, :)

$canonicalName and $requestedName are also passed to the createService Method.
The FactoryInterface just hides these params and it itsn't documented anywhere ....
class Factory implements FactoryInterface
{
    public function createService(ServiceLocatorInterface $sl, $canonicalName = null, $requestedName = null)
    {
        // ...
    }
}

I see. I completely forgot/didn't know this @demichl68 . In all cases, the PR makes this clear (and also simplify it because this refactor remove the distinction between $canonicalName and $requestedName: you always receive a FQCN), and instead adds a new options array that fix a ugly hack of ZF2 (where you had to implement MutableCreationsInterface....)

Yes, I'd rather write an immutable service manager implementation that just skips all the method calls wherever possible (shared services) and inlines any non-shared service instantiation logic.

I'm afraid that this would take away a lot of flexibility.
I always disliked the declare everything and create dozends of factories when there is only a need for a couple and the rest could be done via dependency injection. The current attempt for di is half hearted, and I'd rather see it integrated even better. Most services have dependencies, and writing a factory fetching other instances by class name and injecting them is a waste of time if this could be automated.
If you're really going to do this, create a service manager interface or rely on service locator interface only. Never check for the ServiceManager to allow users to replace the default SM with an implementation that might fit their use case better.
And I could imagine that there are use cases for aliases in the ServiceManager.
Additionally: Where (in terms of filesystem) and when do you want to generate the SM? This should not be at runtime for produvtion. Consider that any sane setup would prevent writing into the application directory for security reasons. Treating the whole application directory as writable is a bad attitude. Also think of apps packaged in a phar.
Take the ZendServer deployment as a good example. The whole application directory ist not writable to the php/webserver user.
Generated code is fine - but it has to be well thought, because it will create vulnerabilities (code injection). Any code you load from writable directories ist potentially compromised.
There should be a compiler for production and the generated code should be immutable. So don't hardcode data/ (besides the horrible assumption the cwd is always the place you're expecting). The application/developer should always have the chance to specify the location.
Doctrine is a good example: It allows codegen at runtime for testing/dev purposes and offers a shell command for pre-generating the code. The target directory for codegen is configurable.
Maybe the generated SM/Factories would be better only an additional option to give the developers the choice which solution fits best.

Hi @tux-rampage ,
As of today, the implementation does not remove many features and does not really change usage. Actually, it can even reduce the number of needed factories by explicitly allowing you to have a class name in the factory, so you can map multiple service names to the same factory (I know, it is possible now but it's not officially supported in the interface, now it will be).
I agree that most services have dependencies, so you have to write one factory per service (mostly). This means a lot of code, and a lot of boring tests to write if you want to tests your factory. HOWEVER, factories are always stupidly simple to write, and at least they allow you to exactly know what happen during the creation process, instead of doing a component doing some magic. For performance it's also quite good (and the new SM performance is really really fast contrary to ZF2).

And I could imagine that there are use cases for aliases in the ServiceManager.

Aliases is not completely gone. I've decided to remove them from the ServiceManager though (and it was @Ocramius idea too) for several reasons:

When we wrote ZF2, we had to support PHP 5.3. At the beginning, we were unsure about what to use as service key. ZF2 is using a mixed between FQCN and short names (like "Router", "ViewManager"...). However, the fact of using the FQCN emerged, as it is always simpler and allows to immediately know which object is created, instead of an opaque "Router". As ZF3 will be PHP 5.5+, we have access to ::class, and this is awesome because it provides you a quick syntax and also powerful refactoring tools in IDE (which was not the case when using strings). The fact that I removed aliases should encourage the paradigm of using ::class keyword, and make everyone's code more coherent.

Aliases introduced an additional overheads: you have to do an additional while loop for each service you create. While not terribly expensive, it can rapidly adds-up for hundreds of objects. And for a critical component like SM, the performance must be tuned and watched. As I said, for most cases, the FQCN is a better choice than aliases. However, there is one case where aliases is useful: some plugin managers like view helper, controller plugin manager. You definitly want to do $this->identity() in your view rather than $this->{'Zend\View\Helper\IdentityHelper'}() (not even sure this syntax is valid).
To that extent, I have introduced a specialized plugin manager that is aware of aliases. You can get best of both worlds: best performance for main service locator and plugin managers that don't need aliases, and flexibility for others.

For the compiler thing, obviously it won't be a runtime compiler. It will work exactly as how Doctrine generation work, and it will be saved to an optimized file that will be used. However, I have tried this and it is far from easy, so we'll likely need some crazy @Ocramius skills to do that.
Finally, for the fact that you need to write factories, I actually tried to use some kind of automatism, through Reflection. I thought that because you had access to the various types through reflection, I could create objects without having to write factories. However, it's not that easy for a lot of reasons:

This only works for objects, not interfaces. As I inject interfaces a lot, this is a case that cannot be handled automatically.
You can't do anything with scalar options.
Plugin managers make things very hard, because any dependencies may actually not come from the main service locator, but from a plugin manager. And knowing which plugin manager the object come from is not that easy. We could argue that plugin managers could be removed in favour of a unique service manager, but plugin managers are really nice and I'd like to keep them.

At the end, there are so many cases where "magic" cannot work, that you end up writing factories 80% of the time anyway. The performance overhead due to the Reflection is also not really acceptable for such a component, tbh.
While it seems appealing, in practice it is not. Speaking about, other people came to the same conclusion. Aura.Di used to do auto-resolution, and they admitted that it was a not-so good idea too: https://github.com/auraphp/Aura.Di#a-note-about-auto-resolution
To conclude, yes, factories are annoying to write, but they are not complex and easy to test, and the most efficient way (except compiling the service manager, but this is another story).

Well I've got your point. But I have to disagree about the 80% of writing factories.
I coupled di and the service manager for zf2 and endet up in writing factories in only 10% of the cases. It's a matter of design.
And I personally like the approach of using and encouraging ::class. It has so much benefits, you named them.
But we should keep the possibility to define services which are no real or invalid (i.e. containing a dot) class names. This still seems to be working. Code should be reusable and subtyping a class just for retrieving a different parameterized shared instance (i.e. another DocumentManager or db adapter) is awful.
The main question from my side is: How do you handle existing classes that are not explicitly defined?
ZF2 had abstract factories.
The easiest (and fastest) approach would simply be to instanciate them with new or fall back to a generic factory.
But why not giving developers a choice here to couple it with Zend\Di (A component I like to have some refactoring for as well) which kicks in when a class is not defined? I think of it in a way where the service manager could be exchanged with a different implementation. That would require changes of typehints to the SM class to an interface. If you're breaking BC it's a good time to clean up a bit more.
So purists can completely ignore di and have max performance and the lazy folks like me can keep things simple and benefit from di by exchanging the servicemanager. I see no reason for preventing possibilities.
About the compiler thingey: Well this would need some specification as well. Maybe it would even be a waste of time and resources if the performance win is not overwhelming. Generated code has cons (it's hard to debug for example). And at the moment I don't see a point where generating code makes the SM more efficient but less maintainable. Maybe I just didn't get the idea here. Please enlighten me.

I just checked your implementation and my concerns about servive names and abstract factories seem to be off the table.
Di could be coupled via an abstract factory.
If I find some time I might offer some refactoring to the di component which will be able to do so.

To be honest I cannot really talk about Di because I have never used this component (except at the very beginning of ZF2 development when we didn't have the Service Manager).
Actually, regarding the key, I want to encourage people to use ::class, but it's just a key. You can still use "doctrine.foo" if you want, as soon as it resolves to a factory that is able to create it. The only use case is for invokables.
In this refactor, everything is a factory (it simplifies implementation and avoid many checks during creation).
Before:
return [
        'invokables' => [
		MyInvokable::class => MyInvokable::class
	],
	'factories' => [
		MyObject::class => MyObjectFactory::class
	]
];

After:
return [
	'factories' => [
		MyInvokable::class => InvokableFactory::class,
		MyObject::class => MyObjectFactory::class
	]
];

InvokableFactory is a built-in factory, and it expects that the service key is actually the FQCN of the class.

Code should be reusable and subtyping a class just for retrieving a different parameterized shared instance (i.e. another DocumentManager or db adapter) is awful.

Actually, this refactor comes with a solution to that. The get method always accept an optional second parameter for options. Contrary to ZF2 where it was only transferred to invokable, in this refactor it is transferred everywhere (even for delegators). This means that your factory is aware of the creation (it is the third parameter of the factory interface), and you can therefore parameterized creation:
$instance1 = $this->serviceLocator->get(MyObject::class, ['foo' => 'bar']);

The only limitation for now is that the service must be marked as non-shared (otherwise, the second time you call the get method, it will return the same instance, without going back to the factory. Actually, I think that we could be smarter here, and assume that if we have options, there are chances that it will be called with another set of options, and hence make this as a criteria to not cache the service. Just an idea, though.

Finally, regarding the compiler, I'm not convinced too. We are using ZF2 for several years, and this refactor is way faster (when I say way faster, it's WAY FASTER !!!), so the performance boost brought by this refactor should be already more than enough ;).

Looks good so far.
Well as said I'd love to support DI here much better, but that's not the business of the ServiceManager, but the Di component. I'd rather see Di as (optional) addon to the ServiceManager.
Plus your implementation already offers a way to do that.
About the second $options parameter, I'm not sure if this would be an overkill here. The Di instance manager offers distinction between parameterized calls and it complicates things a lot.
Of course this is doable, but do we really need it?
Thanks for the effort so far, looks promising. :+1:

I'm closing in favor of the component PR. Please make comments there: https://github.com/zendframework/zend-servicemanager/pull/2


Update build.bat (for working on different axmol build settings)

Describe your changes
Controlling the axmol command over the env: AX_ROOT
Issue ticket number and link
#1801
Checklist before requesting a review
For each PR

[ ] Add Copyright if it missed:
- "Copyright (c) 2019-present Axmol Engine contributors (see AUTHORS.md)."

[x] I have performed a self-review of my code.
Optional:

[ ] I have checked readme and add important infos to this PR.
[ ] I have added/adapted some tests too.

For core/new feature PR

[ ] I have checked readme and add important infos to this PR.
[ ] I have added thorough tests.

Having #1801 in mind, I think it's a bad direction to add more dependencies to AX_ROOT env variable.

@halx99
Is the ios build hanging?

@halx99 Is the ios build hanging?

maybe cmake 3.29.0 random block infinitely

Solved with this changes committed in https://github.com/axmolengine/axmol/commit/197f2adfcd1e23b35f4520eeeccc655acdbe3356


Unable to recognize samsung firmware

Hi all,
first, thanks for this amazing software!
I'm trying to "walk" through the firmware of the Samsung Iconx (2018). It's publicly available here: https://www.samsungimaging.com/file/download?XmlIdx=320&file=ALL_R140XXUAQL2.bin
Or if you prefer from here: https://az335309.vo.msecnd.net/xmlcontainer/customer/data/firmware/xml/SM-R140FOTA_global_201712210608_s.xml
When I use binwalk on it I don't see anything.
foo $ binwalk firmware.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------

Then I scanned the opcodes and as I imagined I see:
foo $ binwalk -A firmware.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
46468         0xB584          ARM instructions, function prologue
386749        0x5E6BD         ARM instructions, function prologue

And here the entropy:

Do you have any idea how I can extract this bin?
Thanks so much!

@DAddYE I got a firmware from here.  Any idea can flash it to my  Iconx (2018). I want to downgrade my device.
You can download the file from google drive https://drive.google.com/open?id=1_XIIGUhGJkjMvIfVfjg-Qnbibi0YAoBy

ALL_R140XXUAQL2.bin it is only patch file I think


FlashpointInfinity 9.0

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

Microsoft Reviewers: Open in CodeFlow

A dialog appears at the end of setup blocking install.  You must dismiss the dialog and then you get error 2

This app must be installed in an elevated shell microsoft/winget-cli#152


SwapChain.Present and SwapChain1.Present now return their result codes.

…so that the application can check whether the window is occluded. This should resolve #746.

Thanks!


404 at: /installation/ubuntulinux/

URL: /installation/ubuntulinux/

Which page linked to that url?
https://docker.github.io/engine/installation/linux/ubuntulinux/ seems to be the correct one.

Thanks @prashanth-rg :)


Better editor for large # of groups.

 Id gladly show you a luckperms editor link (in private) to see what I mean.
https://image.ibb.co/gHfgcT/asd.png
This is genuinely the one thing I dislike with LuckPerms, even though I love the damn project so much so never really brought it up. If you could somehow do some magic for us in this department, <3
Idea I've had in the past:
Regex support:
/lp editor groups main_*
(would find all groups starting with main)
this was turned down by Luck however.
New idea would be to maybe give us a vertical scroll:
https://image.ibb.co/iisNj8/asd.png
Or, give us a search bar which we can use to type in a group name.
Yes, I absolutely understand the command /lp editor groupname exists, however, working in bulk, efficiently, dealing with MANY groups of the same prefix, while having 300 groups, is RIP lol.
Anyways, thought I've give this request a shot on github, if web editor is simply not a priority for you at all close it off, all good. Again I love this project very much and this is just something that would give us that final blessing lol.

These suggestions should now be added in v2 of the web editor, please update to LuckPerms v5 to use it.


Doesn't work on MacOS, iPad, iPod

The maze isn't drawn.
When the game runs, the player's maze, which is a canvas, is manipulated (e.g. each pill are removed) and then it is drawn onto the main output canvas.
This works on Windows/Android on all browsers, but doesn't work on Apple.

The maze isn't drawn.
When the game runs, the player's maze, which is a canvas, is manipulated (e.g. each pill are removed) and then it is drawn onto the main output canvas.
This works on Windows/Android on all browsers, but doesn't work on Apple.

Perhaps this is related?
https://stackoverflow.com/questions/42700396/canvas-element-not-rendering-on-ios-devices

Sound also does not work on same platforms (Safari on MacOS, iOS)


SOLR-15248 Disable login autocomplete

Description
Remove login autocomplete, which currently allows you to see who had previously logged in.
Solution
Add autocomplete=off
Tests
Go to the login page and confirm that clicking in the username box doesn't show other users.
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.
[X] I have run ./gradlew check.
[ ] I have added tests for my changes.
[ ] I have added documentation for the Reference Guide

Have you tested the fix and see it's working?

Yes. I also tested it with a password manager (I used LastPass).
Before, with password manager

After, with password manager

Before, in chrome incognito mode

After, in chrome incognito mode

Looks good. Will merge and target v9.0


Bootstrap 4

I use a lot more Bootstrap 4 these days - if I modify the Templates would you add them to this Project?
This way we would have BS4 options for Building Admin Panels

Could please share those templates?

We need to sort out it on appzcoder/crud-generator package

Guys, Please use the new update to use the bootstrap 4


Frontend should depend on config

Description:
frontend now depends on config since the default lovelace will organize entities by area.
Related issue (if applicable): fixes #23956
Pull request with documentation for home-assistant.io (if applicable): home-assistant/home-assistant.io#<home-assistant.io PR number goes here>
Example entry for configuration.yaml (if applicable):

Checklist:

[ ] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass
[ ] There is no commented out code in this PR.
[ ] I have followed the development checklist

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
[ ] New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
[ ] Untested files have been added to .coveragerc.

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

We had this rule that no integration was allowed to depend on config because it meant that a using a dependency you open up the API to manage configuration. However, this rule might not be necessary anymore now that we have an authentication system and a dedicated admin group. I am willing to lift the restriction once we have audited and confirmed that none of the config APIs are accessible to non-admin users.

That is more complex than one line change, the proper fix is create the area list WS commond in front end component.

What's the plan here?

We need to audit all actions on the config panel to make sure that they require admin access for any write access. When that's the case, we can lift the restriction that config cannot be a dependency.

So then we can close this PR for now?

Yes.


Rework Twitch Integration

Breaking change

TBD
Proposed change

TBD
Type of change

[ ] Dependency upgrade
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New integration (thank you!)
[x] New feature (which adds functionality to an existing integration)
[x] Breaking change (fix/feature causing existing functionality to break)
[x] Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

# Example configuration.yaml

Additional information

Link to documentation pull request: TBD

Checklist

[ ] The code change is tested and works locally.
[ ] Local tests pass. Your PR cannot be merged unless tests pass
[ ] There is no commented out code in this PR.
[ ] I have followed the development checklist
[ ] The code has been formatted using Black (black --fast homeassistant tests)
[ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] The manifest file has all fields filled out correctly.
Updated and included derived files by running: python3 -m script.hassfest.
[ ] New or updated dependencies have been added to requirements_all.txt.
Updated by running python3 -m script.gen_requirements_all.
[ ] Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

[ ] No score or internal
[ ] 🥈 Silver
[ ] 🥇 Gold
[ ] 🏆 Platinum

When you work on something and completely miss the fact that someone is already making a change to the integration once you push... Oh well good practice :smile:
It would be nice to get this integration into the entity registry though, since adding streamers via the ui is super simple

Would really appreciate a way to add this via UI :) Maybe you can create a follow up PR, that is based on #31122 with config flow?


Update signal-hook-tokio for tokio v1.0

This drops support for pre-1.0 versions of tokio, and removes the per-version features and modules.
Fixes #83.

Codecov Report

Merging #87 (77703ea) into master (1f271a0) will decrease coverage by 1.78%.
The diff coverage is 85.71%.

@@            Coverage Diff             @@
##           master      #87      +/-   ##
==========================================
- Coverage   63.05%   61.26%   -1.79%
==========================================
  Files          26       27       +1
  Lines        3762     3565     -197
  Branches      145      181      +36
==========================================
- Hits         2372     2184     -188
+ Misses       1389     1380       -9
  Partials        1        1

Impacted Files
Coverage Δ

signal-hook-tokio/src/lib.rs
92.59% <84.61%> (+2.59%)
:arrow_up:

signal-hook-tokio/tests/tests.rs
100.00% <100.00%> (ø)

src/flag.rs
74.41% <0.00%> (-17.01%)
:arrow_down:

signal-hook-registry/src/half_lock.rs
75.36% <0.00%> (-2.98%)
:arrow_down:

src/lib.rs
47.39% <0.00%> (-2.82%)
:arrow_down:

build.rs
85.93% <0.00%> (-1.95%)
:arrow_down:

src/low_level/siginfo.rs
70.96% <0.00%> (-1.59%)
:arrow_down:

src/low_level/mod.rs
50.00% <0.00%> (ø)

src/low_level/signal_details.rs
27.27% <0.00%> (ø)

examples/print.rs
0.00% <0.00%> (ø)

Codecov Report

Merging #87 (77703ea) into master (1f271a0) will decrease coverage by 1.78%.
The diff coverage is 85.71%.

@@            Coverage Diff             @@
##           master      #87      +/-   ##
==========================================
- Coverage   63.05%   61.26%   -1.79%
==========================================
  Files          26       27       +1
  Lines        3762     3565     -197
  Branches      145      181      +36
==========================================
- Hits         2372     2184     -188
+ Misses       1389     1380       -9
  Partials        1        1

Impacted Files
Coverage Δ

signal-hook-tokio/src/lib.rs
92.59% <84.61%> (+2.59%)
:arrow_up:

signal-hook-tokio/tests/tests.rs
100.00% <100.00%> (ø)

src/flag.rs
74.41% <0.00%> (-17.01%)
:arrow_down:

signal-hook-registry/src/half_lock.rs
75.36% <0.00%> (-2.98%)
:arrow_down:

src/lib.rs
47.39% <0.00%> (-2.82%)
:arrow_down:

build.rs
85.93% <0.00%> (-1.95%)
:arrow_down:

src/low_level/siginfo.rs
70.96% <0.00%> (-1.59%)
:arrow_down:

src/low_level/mod.rs
50.00% <0.00%> (ø)

src/low_level/signal_details.rs
27.27% <0.00%> (ø)

examples/print.rs
0.00% <0.00%> (ø)

Thank you :-). Looks good.
Do you want to follow up with that cleanup right away, or should I spin up a release?

Thank you :-). Looks good.
Do you want to follow up with that cleanup right away, or should I spin up a release?


bugfix(modflow.py): need to specify delc for pixel width and rot angle

Two small things for getting affine from modelgrid.json:
First, if the a parameter is the width of a pixel, this should be delc rather than delr.
Second, I got goofy results on a rotated grid relative to a transform made using modflow-export usingMFexportGrid. The difference was the b and e had opposite sign. Flipping the sign in the Affine().rotation(angle) call fixed this. However, I realize this is inconsistent with the docstring here: https://github.com/rasterio/affine/blob/master/affine/tests/test_rotation.py. Maybe the modegrid.json convention is reversed? In any case, making this switch resulted in proper results for this rotated model (18 degrees anticlockwise) and not reversing the angle resulted in negative values for r in the get_ij funciton.

Hey @mnfienen thanks for taking a look at this.
TL;DR- are you sure that delc/delr are consistent on your end, or is there an issue with how Modflow-setup is writing them to the grid.json file? We want to keep delc/delr as-is, but I think you're right that the rotation angle needs to be inverted.
Re delc/delr: I believe the a parameter is spacing in the x direction, which would correspond to delr (spacing along a row). Maybe confusing, but that's how Flopy (and maybe Modflow?) does it, so I follow that convention for Modflow-setup to avoid confusion, especially in working with the DIS package and model grid object.
Re: rotation- I think we follow the Flopy convention for the direction of angrot (positive counter clockwise for an origin in the lower left corner). The Flopy grid docstring unfortunately doesn't say anything about direction, but I think I'd have to be the same, otherwise we'd run into trouble with the subclassed grid object in Modflow-setup.
I think maybe the confusion is in what origin is used. In Modflow-setup, the MFsetupGrid object accepts either the lower left or upper left corner to define the grid location, but the rotation direction (positive CCW) is always about the lower left corner. In contrast, the affine.Affine instance for the transform attribute is always defined based on the upper left corner (hence the negative y-spacing), so we have to flip the rotation sign to get rotation in the same direction. For example,  consider a simple grid with the lower left at 0, 0 and a 45 degree rotation ccw.
from affine import Affine
trans_ll = Affine(1, 0, 0,
                  0, 1, 0)

the upper left corner is:
trans_ll * Affine.rotation(45) * (0, 1)
(-0.7071067811865475, 0.7071067811865476)

we can redefine that with a new Affine object with the same upper left:
trans_ul = Affine(1, 0, -0.707,
                  0, -1, 0.707)

to get the same lower left as the first instance, we need to flip the rotation sign
trans_ul * Affine.rotation(-45) * (0, 1)
(0.00010678118654772195, -0.0001067811865474999)

hey @aleaf  - oh man, I'm always reverseing delr and delc in MODFLOW! The original issue was that both values were delr but I agree I changed the wrong one. I will fix.
for the rotation issue, you must have gone down this road before in modflow-export because here's how the transform is calculated there - on the MFexportGrid object:
@property
def transform(self):
    """Rasterio Affine object (same as transform attribute of rasters).
    """
    return Affine(self.delr[0], 0., self.xul,
                  0., -self.delc[0], self.yul) * \
           Affine.rotation(angle=-self.angrot)

Note the negative angle specification - the results from modflow-export are oriented correctly, so one way or another, I think we need the negative angle. Calling this, the angle was positive and meant to be anticlockwise, so should be consistent. Also, I see I did reverse delr and delc as you noticed. I commited that correction


first NOTE should be removed

"Azure PowerShell is only available on Windows clients." This is incorrect.  The AZ module, version 2.1.0, is working perfectly well on Ubuntu for me. If you mean the old ASM thing, then you should make that FAR clearer.

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

ID: 2700c253-d5ff-d166-7338-d9238044e210
Version Independent ID: c4dc47e3-2a10-0ee3-1d39-bebf3ed77b51
Content: Create Apache Hadoop clusters using PowerShell - Azure HDInsight
Content Source: articles/hdinsight/hdinsight-hadoop-create-linux-clusters-azure-powershell.md
Service: hdinsight
GitHub Login: @hrasheed-msft
Microsoft Alias: hrasheed

@lukeb1961 Thanks for bringing this to our notice. We are investigating into the issue and will update you shortly.

@lukeb1961 Azure Powershell is available only for Windows clients as windows has powershell and .NET already installed, which are needed to run AZ module.
For linux, it is recommended to  Create a Linux-based HDInsight cluster using Azure Classic CLI .
Have you installed .NET Core on Ubuntu and are running AZ powershell on top of that ?

@hrasheed-msft Can you please take a look at this one ? Please check this blog out.

https://github.com/MicrosoftDocs/azure-docs-pr/pull/77928

@lukeb1961 Thanks for bringing it to our attention. Resolved in linked PR.

#please-close


Fix credentials not being prompted on first run

Fixed in https://github.com/chowder/ttv-cli/commit/bf424040cd26b1f421c126b1b530aff394f4d647


Support ES module import

Enables importing like this:
import * as usearch from 'usearch'
https://nodejs.org/api/packages.html#conditional-exports
Without this fix I was seeing this error message:
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main defined in .../node_modules/usearch/package.json

:tada: This PR is included in version 2.9.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


woqlClient should be named TerminusDB Client

The client should be named TerminusDB client instead. The name of the query language should not be in every object.

See https://github.com/terminusdb/terminusdb-client-python/issues/260 for Python Client.

We already did this for the Python client now but should be done for the JS client too.


Uncaught error when evaluating improper level formula, causing the page to break

https://github.com/FoskyM/flarum-custom-levels/blob/3e700da51e0855de54aebcfc68f750fe937204bf/js/src/forum/components/LevelBar.js#L33
The use of eval here is unsafe (XSS, etc.). The evaluation will fail if the formula is not defined properly, causing the page to break. I recommend that you apply error handling to this part of the code, ensure that all the inputs contain the necessary variables that need to be replaced, or even better, not use raw eval at all (although I understand that finding a suitable replacement without introducing too much complexity to the existing code is not ideal).

Okay. I'll try to handle the error if available. And adding a verification for the formula input seems to be a good choice as well?
This extension was first made for myself. Though I know that eval is unsafe actually, but as you said, I can't find a suitable alternative until now.
Thanks!

Thank you for your response, I understand :)
Decided to report this, as couple of users occasionally run into this issue at FreeFlarum and don't know what to do because their forum breaks for no apparent reason (so some error handling would be nice so that the page may continue loading)


Trusting LiveShare session causes '/' to be trusted

Start LiveShare of msft/vscode in one window
In different window, join the session
See request for trust, Manage Trust, then click the Trust button
See that / has been trusted

I note that when I open the workspace folder config file, I see:
{"folders":[{"uri":"vsls:/","name":"vscode"}],"settings":{"vsliveshare.join.reload.workspaceId":"A47ECCA424D135C1535B3F600E6CD66174B0","vsliveshare.join.reload.workspaceFolder":"/var/folders/4x/stmrc1tj4wx8j31phlphkvvh0000gn/T/vsliveshare-tmp-A47ECCA424D135C1535B3F600E6CD66174B0","files.hotExit":"off"}}

fixed with trusting of VFS paths


Implementation in Texpad

Hello,
I am quite new to using latex so I hope this question is not totally weird. I just got a suggestion in a forum to use the ext-authoryear style for redesigning the citationstyle. I was told to easily drag the files in my latex project folder to make it work.
So I did but I still get an error message which says "package not found"
Do you have any idea how I can get the ext-authoryear package to work with Texpad on a Mac? I am not using MacTex.
Felix

I wonder whoever gave you that idea ... ;-)
Anyway, there are a few things going on here. You may want to read a general introduction to TeX and LaTeX to understand what this is about.
In order to use LaTeX you normally install a so-called TeX distribution. That distribution installs some binaries (such as pdfLaTeX, LuaLaTeX, ...) as well as further packages and means to use them.
There are three major distributions nowadays (but there were/are more: https://tex.stackexchange.com/q/239199/)

MikTeX for Windows, experimental support for Mac OS and Linux
TeX live for Win, Linux and Mac
MacTeX (based on TeX live) for Mac, naturally

You must have one of these installed to be able to use (La)TeX. It is via your TeX distribution that you install and update packages.
Texpad is only an editor, just like TeXworks, TeXstudio, ... You simply write your .tex files there. Most editors have options to call LaTeX and other auxiliary programmes for you. But they can not do that without an underlying TeX distribution. (See for example in "What if I haven’t yet installed LaTeX?" on Texpad's support pages)
Now MacTeX is based on TeX live and TeX live has the peculiarity that it is "frozen" for a few weeks a year and that you have to do a full re-install each year to continue to get updates. Have a look at https://tex.stackexchange.com/q/107017/35864 for explanations. MikTeX does not work like that and offers continuous updates all year round. biblatex-ext was first released after the TeX live freeze, so at the moment biblatex-ext is only available in MikTeX and in TeX live 2018 pretest (not for production use).
Since you are on a Mac you are most likely using MacTeX or raw TeX live in both of these cases you will not be able to install biblatex-ext automatically at the moment.
If you want to use the package regardless, download the files from GitHub and place the .bbx, .cbx and .def files in the same directory as your main .tex file. Do not move them to a subdirectory.
If that does not help, please share more about your folder set-up, where exactly you placed which files, the error messages you receive, etc. etc.

Thanks so much I got some very smart supporters here ;)
I think this gave me an excellent overview across the whole topic plus solved my problem!

Very well. I'll close this ticket then.


Upgrade the UBI for the Market Reader

The current UBI in the Dockerfile has some known vulnerabilities. Upgrade to the latest UBI.

Updated in quay.io/brbaker/market-pricing:v0.4.4


log output

+fix verbose flag

This is interesting, will you examine the log file when a benchmark fails? Is this the purpose?

I thought this was the idea stated in #31. Was the aim of #31 something different?


Add NaN and NotNaN operators (+ CmpNaN/NotNaN & T.CmpNaN/NotNaN)

Solves #24
Signed-off-by: Maxime Soulé<EMAIL_ADDRESS>

Pull Request Test Coverage Report for Build 121

64 of 64 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 99.057%

Totals

Change from base Build 118:
0.02%

Covered Lines:
3677

Relevant Lines:
3712

💛  - Coveralls

Pull Request Test Coverage Report for Build 121

64 of 64 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 99.057%

Totals

Change from base Build 118:
0.02%

Covered Lines:
3677

Relevant Lines:
3712

💛  - Coveralls


fix: First OIDC account is not admin

Pull Request Checklist
Note to first-time contributors: Please open a discussion post in Discussions and describe your changes before submitting a pull request.
Before submitting, make sure you've checked the following:

[x] Target branch: Please verify that the pull request targets the dev branch.
[x] Description: Provide a concise description of the changes made in this pull request.
[x] Changelog: Ensure a changelog entry following the format of Keep a Changelog is added at the bottom of the PR description.
[x] Documentation: Have you updated relevant documentation Open WebUI Docs, or other documentation sources?
[x] Dependencies: Are there any new dependencies? Have you updated the dependency versions in the documentation?
[x] Testing: Have you written and run sufficient tests for validating the changes?
[x] Code review: Have you performed a self-review of your code, addressing any coding standard issues and ensuring adherence to the project's coding standards?
[x] Prefix: To cleary categorize this pull request, prefix the pull request title, using one of the following:

BREAKING CHANGE: Significant changes that may affect compatibility
build: Changes that affect the build system or external dependencies
ci: Changes to our continuous integration processes or workflows
chore: Refactor, cleanup, or other non-functional code changes
docs: Documentation update or addition
feat: Introduces a new feature or enhancement to the codebase
fix: Bug fix or error correction
i18n: Internationalization or localization changes
perf: Performance improvement
refactor: Code restructuring for better maintainability, readability, or scalability
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
test: Adding missing tests or correcting existing tests
WIP: Work in progress, a temporary label for incomplete or ongoing work

Changelog Entry
Description

FIX errors with auth through OIDC (openid).

Fixed

#3496 First user with OIDC (openid) provider is not admin.
Write full openid information write to cookie, instead of jwt_token.

Is this no longer necessary? You closed your issue #3496

Is this no longer necessary? You closed your issue #3496

Hi! Actual. I closed #3496 because I formed a PR. Should I open issues?

Good catch, Thanks!


cnspec: 10.2.0 -> 10.6.1

Diff: https://github.com/mondoohq/cnspec/compare/refs/tags/v10.2.0...v10.6.1
Changelog: https://github.com/mondoohq/cnspec/releases/tag/v10.6.1
Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

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

1 package built:

cnspec


Network constructin could not be completed due to an error

When I am hitting generate network, an error appears saying Network constructin could not be completed due to an error.

Hi, have you solved this issue, I am running into the same issue using the sample data.

@shuxij in this case it was a problem encountered with installing through anaconda navigator. If you also installed using anaconda navigator, please remove the environment and use the installation script. Otherwise, please explain any new issues with installation steps and steps taken to attempt to generate a network.

@Jmegan042 Thanks for the reply. I removed and re-installed Madbyte. The same error message again.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "D:\0_课题\NMR计算\madbyte-1.4.1\madbyte-1.4.1\madbyte\gui.py", line 35, in run
result = self.fn(
^^^^^^^^
File "D:\0_课题\NMR计算\madbyte-1.4.1\madbyte-1.4.1\madbyte_init_.py", line 72, in correlation_matrix_generation
core.construct_correlation_matrix(
File "D:\0_课题\NMR计算\madbyte-1.4.1\madbyte-1.4.1\madbyte\core.py", line 133, in construct_correlation_matrix
corr_mat = utils.compute_corr_matrix(ss_df, hppm_error, cppm_error)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\0_课题\NMR计算\madbyte-1.4.1\madbyte-1.4.1\madbyte\utils.py", line 443, in compute_corr_matrix
results = Parallel(n_jobs=-1)(
^^^^^^^^^^^^^^^^^^^^
File "C:\Users\shuxi\AppData\Local\Programs\Python\Python311\Lib\site-packages\joblib\parallel.py", line 2007, in call
return output if self.return_generator else list(output)
^^^^^^^^^^^^
File "C:\Users\shuxi\AppData\Local\Programs\Python\Python311\Lib\site-packages\joblib\parallel.py", line 1650, in _get_outputs
yield from self._retrieve()
File "C:\Users\shuxi\AppData\Local\Programs\Python\Python311\Lib\site-packages\joblib\parallel.py", line 1754, in _retrieve
self._raise_error_fast()
File "C:\Users\shuxi\AppData\Local\Programs\Python\Python311\Lib\site-packages\joblib\parallel.py", line 1789, in _raise_error_fast
error_job.get_result(self.timeout)
File "C:\Users\shuxi\AppData\Local\Programs\Python\Python311\Lib\site-packages\joblib\parallel.py", line 745, in get_result
return self._return_or_raise()
^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\shuxi\AppData\Local\Programs\Python\Python311\Lib\site-packages\joblib\parallel.py", line 763, in _return_or_raise
raise self._result
ValueError: Inclusive has to be either string of 'both','left', 'right', or 'neither'.

Hi @shuxij - this occurs because pandas > 2.0 is installed in the environment. We outline the environment in the environment.yml file, but sometimes if this is done without setting up a new environment, a newer version of pandas causes this issue.

Hi, have you solved this issue, I am running into the same issue using the sample data.

Yes, I have managed to do it with sample data so far. It is working only with my Windows system, in case that helps.


Move fontbakery-build-metadata.py here

Looks to me like 1. this repo needs better name (eg googlefonts-metadata) or just invent a name for it.  And that fontbakery-build-metadata.py should live here (and be improved as needed).

Looks to me like 1. this repo needs better name (eg googlefonts-metadata) or just invent a name for it.

The googlefonts is already in the organization name.

And that fontbakery-build-metadata.py should live here (and be improved as needed).

Its no longer a standalone script.

The googlefonts is already in the organization name; this is a temporary repo, I expect we'll include it into the main /google/fonts repo when the gf team have reviewed it :)

Ok I thought you are going to push this format to be used more broadly.

I first made this so other font distributors (webfont providers or package makers) can better utilize the Google Fonts structure. This metadata is tied to Google Fonts specifically, but since the Google Fonts repo also happens to be a handy, consistently organized collection of libre fonts, it's useful to be able to make sense of the metadata files.


GREYElementMatcherBlock is not working in Earlgrey2

Found an issue while migrating to Earlgrey 2.. We've been using GREYElementMatcherBlock to fetch children under a parent of specific type.. ex: cells under a table view... With Earlgrey 2, when the matcher block is called with EDOObject, the call is getting stuck...
Here's the sample code
func queryForChildren(type: AnyClass, parent: String) -> [String] {
        var elements:[String] = []

        let matcher = grey_allOf([
            grey_kindOfClass(type),
            grey_ancestor(grey_allOf([grey_accessibilityID(parent)]))
        ])

        let queryMatcher = GREYElementMatcherBlock.matcher(matchesBlock: {
            obj -> Bool in
            guard matcher.matches(obj) else {
                return false
            }

            let view = obj as AnyObject
            elements.append( view.accessibilityLabel)
            return true
        }, descriptionBlock: { (description) in
            description.appendText("Element Query Matcher")
        })

        var error: NSError? = nil
        EarlGrey.selectElement(with: queryMatcher)
          .assert(grey_notNil(), error: &error)

        return elements
    }

Earlgrey thread goes to a wait/frozen state at matcher.matches(obj) call and never returns back.

Any updates on this?


Depth Map shows tilted floor

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

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

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

Required Info

Camera Model
D435

Firmware Version
5.11.1

Operating System & Version
MacOS

Kernel Version (Linux Only)
---

Platform
Mac

SDK Version
2.13.0

Language
nodejs

Segment
others

Issue Description
I have a camera mounted parallel to the floor. If I use nodejs-save-to-disk.js example, the depth map show a tilt from left to right.  The tilt is much smaller but still noticeable:

Why can I see this heavy gradient on the floor, even all pixels on the floor have a distance of 34-35cm?

When converting depth to RGB / gray-scale we usually apply histogram equalization. Practically it means that the algorithm has to use every color in the color map. When looking at a flat surface it will pick up on the gradient caused by the angle between the plane and the camera and visually emphasize it.

But the right side of the image (34cm) has almost the same color as the right side of the box (29cm)

Well, it is not exactly the same color. Histogram equalization will stretch the range of allowed colors over the depth values that are in the scene. So in this case it can be:
[35.1-35.08] black to gray
[35.08-29.1] still gray, since there are no actual pixels in the scene in that range
[29.1-29.02] gray to white
You can control the behavior of the colorizer class from code to disable this effect.

How can I config the colorizer with node.js? Unfortunately the node docs are a little limited

Hi
Sorry for taking a while to come over to this one.
You may go back to C++ code and play with enabling/disabling histogram equalization and see how it helps:
https://github.com/IntelRealSense/librealsense/blob/master/src/proc/colorizer.cpp#L133
Hope this can be helpful.
Thanks!

Hi LucidityDesign,
Wonder if there is any update on this one? Do you still need help?
Thanks!

Thanks for coming back. I haven't tried to modify the colorizer but ended up drawing my maps via canvas. The results were sufficient for us.


Added pastel minimalist button

Added animated pastel minimalist style button

Please accept submission under hacktoberfest label, thanks.

@anu-codes  Thank you for your contribution. 🤩
Leave a star if you like. 🌟

@Spyware007 Starred, thanks for letting me contribute to this project! Please add the hacktoberfest label on my PR :)


add Vocabulary

Add Vocabulary for word and index one to one mapping
        vocab = Vocabulary()
        word_list = "this is a word list".split()
        vocab.update(word_list)
        vocab["word"] # get the index of "word"
        vocab.to_word(5) # get the word of index 5

@choosewhatulike
One more thing:
The high-level API FastNLP in fastnlp.py relys on word2id.pkl and id2label.pkl.
Changes should be made there as well.

Codecov Report

Merging #82 into master will increase coverage by 0.32%.
The diff coverage is 85.47%.

@@            Coverage Diff            @@
##           master     #82      +/-   ##
=========================================
+ Coverage   61.77%   62.1%   +0.32%
=========================================
  Files          64      66       +2
  Lines        3618    3681      +63
=========================================
+ Hits         2235    2286      +51
- Misses       1383    1395      +12

Impacted Files
Coverage Δ

test/model/test_cws.py
30% <0%> (ø)
:arrow_up:

fastNLP/fastnlp.py
45.31% <0%> (ø)
:arrow_up:

test/core/test_predictor.py
100% <100%> (ø)
:arrow_up:

fastNLP/core/predictor.py
79.03% <80%> (ø)
:arrow_up:

fastNLP/core/vocabulary.py
86% <86%> (ø)

fastNLP/core/preprocess.py
81.29% <87.5%> (-0.8%)
:arrow_down:

test/core/test_vocab.py
96.29% <96.29%> (ø)

fastNLP/modules/utils.py
63.63% <0%> (-3.21%)
:arrow_down:

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 4d66bd6...819c8f0. Read the comment docs.

ok, fixed now

@choosewhatulike
If self.word2idx = {}, in def __getitem__(self, w):  self.word2idx[DEFAULT_UNKNOWN_LABEL]  will throw an error.
Is this an expected behavior ?

Well, The need_default is set to False when self.word2idx = {}, which means you are confident that there are no “out of vocabulary” when you indexing the words. So I think an exception is not wrong this time.
Think I need to add a more human readable exception.


Console log does not display correctly in windows7

ANSI escape code (ex. \033[J) is used in logging function (ex. progress_bar), and the text which contains ANSI escape code cannot display correctly in windows (except windows10) console view.
if you have counter-measure, please fix this problem.
thank you for reading, and hope my english mistake haven't put you off.

+1 . The logging function fails to display properly in Windows 8.1 (running mnist example)

Thanks for your support!

I think this issue has been solved in #1730. Please reopen if it persists.


Uncaught TypeError: Cannot read property 'blockHeight' of undefined

[Enter steps to reproduce:]

...
...

Atom: 1.20.1 x64
Electron: 1.6.9
OS: Mac OS X 10.12.6
Thrown From: Atom Core
Stack Trace
Uncaught TypeError: Cannot read property 'blockHeight' of undefined
At /Applications/Atom.app/Contents/Resources/app/node_modules/line-top-index/dist/line-top-index.js:313

TypeError: Cannot read property 'blockHeight' of undefined
    at LineTopIndex.adjustNodeBlockHeight (/Applications/Atom.app/Contents/Resources/app/node_modules/line-top-index/dist/line-top-index.js:313:17)
    at LineTopIndex.removeBlock (/Applications/Atom.app/Contents/Resources/app/node_modules/line-top-index/dist/line-top-index.js:78:18)
    at marker.bufferMarker.onDidChange (/Applications/Atom.app/Contents/Resources/app/src/text-editor-component.js:2524:35)
    at Function.module.exports.Emitter.simpleDispatch (/Applications/Atom.app/Contents/Resources/app/node_modules/event-kit/lib/emitter.js:25:20)
    at Emitter.module.exports.Emitter.emit (/Applications/Atom.app/Contents/Resources/app/node_modules/event-kit/lib/emitter.js:141:34)
    at Marker.module.exports.Marker.emitChangeEvent (/Applications/Atom.app/Contents/Resources/app/node_modules/text-buffer/lib/marker.js:424:26)
    at /Applications/Atom.app/Contents/Resources/app/node_modules/text-buffer/lib/marker-layer.js:324:31
    at Set.forEach (native)
    at MarkerLayer.module.exports.MarkerLayer.emitChangeEvents (/Applications/Atom.app/Contents/Resources/app/node_modules/text-buffer/lib/marker-layer.js:321:52)
    at TextBuffer.module.exports.TextBuffer.emitMarkerChangeEvents (/Applications/Atom.app/Contents/Resources/app/node_modules/text-buffer/lib/text-buffer.js:1561:40)
    at TextBuffer.module.exports.TextBuffer.transact (/Applications/Atom.app/Contents/Resources/app/node_modules/text-buffer/lib/text-buffer.js:924:18)
    at TextEditor.module.exports.TextEditor.transact (/Applications/Atom.app/Contents/Resources/app/src/text-editor.js:1673:32)
    at TextEditor.module.exports.TextEditor.moveCursors (/Applications/Atom.app/Contents/Resources/app/src/text-editor.js:2174:25)
    at TextEditor.module.exports.TextEditor.setCursorScreenPosition (/Applications/Atom.app/Contents/Resources/app/src/text-editor.js:1969:25)
    at TextEditorComponent.didMouseDownOnContent (/Applications/Atom.app/Contents/Resources/app/src/text-editor-component.js:1805:25)

Commands
  2x -2:04.0 core:backspace (input.hidden-input)
     -2:00.9.0 editor:newline (input.hidden-input)
     -1:58.8.0 core:backspace (input.hidden-input)
     -1:57.2.0 core:save (input.hidden-input)

Non-Core Packages
angularjs 0.4.0
atom-beautify 0.30.5
atom-bracket-highlight 0.3.2
atom-jump-block 0.5.4
atom-wrap-in-tag 0.6.0
autoclose-html 0.23.0
autocomplete-module-import 0.1.2
autocomplete-modules 1.7.0
base16-ocean-dark-spacegray 0.13.0
better-window-title 1.0.3
busy-signal 1.4.3
css-in-js 1.4.0
cssbeautify 1.3.0
editorconfig 2.2.2
emmet 2.4.3
file-icons 2.1.12
highlight-selected 0.13.1
import-cost-atom 1.0.4
intentions 1.1.5
js-func-viewer 1.1.4
language-babel 2.74.3
letter-spacing 0.3.1
linter 2.2.0
linter-eslint 8.3.2
linter-ui-default 1.6.10
minimap 4.29.7
minimap-cursorline 0.2.0
minimap-find-and-replace 4.5.2
minimap-highlight-selected 4.6.1
minimap-pigments 0.2.2
minimap-quick-highlight 1.0.1
oceanic-next 1.0.0
open-project-file 1.1.1
pigments 0.40.2
platformio-ide-terminal 2.7.0
react 0.16.2
react-snippets 0.9.0
single-click-open 0.2.2
speed-bot 0.1.0
sync-settings 0.8.3
tree-view-open-files 0.3.0
whitespacer 1.1.1

Thanks for the report!  Can you confirm a few things for us?

what were you doing at the time of the error?
is the error is reproducible?
if reproducible, do you see the error in safe mode (atom --safe)?

I was doing select all and paste all

Thanks for the details - so the error is reproducible for you with those steps?  If so, can you clarify your steps?

I am selecting text in a file > then select all in another file.

When you say select, do you mean select and copy?

I got the error when I want to paste

Where are you pasting?  In file 1 or 2 or it doesn't matter?

I have to delete before pasting in order not to have the error

What do you delete before pasting?
A GIF or screencast could be helpful too.

I am selecting text in a file and copy > then select all in another file.
All the text is selected on the new file, I paste the I got the error message

I think it might be caused by my package, import-cost-atom - been struggling to figure out what's going on. Also reported here: https://github.com/IanMitchell/import-cost-atom/issues/5
For repro steps, install my package, create a new Node project with something like
import debug from 'debug';

const log = debug('test');
log('Hello World');

With the corresponding package.json with debug dependency. The import line should be marked up - selecting the line and deleting it should trigger this error.
As far as I can tell, my package gets through everything without problem but something that's leftover is mucking with the line and preventing it from being removed. Been tearing my hair out trying to figure out what I'm doing wrong haha

Should be fixed now - @jeromelachaud do you still get the exception after updating to the latest version of import-cost-atom?

Oh awesome @IanMitchell - just to clarify, do you think there's an issue on our end that we should ask the team to look at?

@IanMitchell , I have just updated the package and so far, so good 👍
Keeping this issue opened for a few hours to confirm the problem is gone and I'll dully close it.
Thanks @rsese as well

@rsese @jeromelachaud We should keep this open and ask the team about it.

@rsese I don't believe so - the only thing I'd mention is that the exception never mentioned my package, and the stack trace didn't have any hints either. I know the language-babel folk also got a bug report that came through Atom, even though the root cause was my fault (see: https://github.com/gandm/language-babel/issues/415)
I don't know if it's worth the effort to investigate / try to fix though since it seems this issue is a pretty rare one.

@IanMitchell There is now a PR open to fix this. Thank you for the clear steps to reproduce :bowing_man:


Unable to connect to Neo4j APOC Plugin

When I run the app, I get this error

, I am unsure how to fix this.

Sorry for the late reply here, seems like this is an issue with Neo4j database configurations. APOC is just a library that Neo4j uses to add more functionality, with every Neo4j aura instance, APOC should be automatically integrated, but if you are hosting the instance on your own machine, you usually have to download and enable APOC manually. Are you connecting to an aura instance or is the database self hosted?

version: '3.7'
services:
  neo4j-v3:
    image: neo4j:5.21.2
    ports:
      - "27474:7474"
      - "27687:7687"
    environment:
      - NEO4J_AUTH=neo4j/root1234
      - NEO4J_apoc_export_file_enabled=true
      - NEO4J_apoc_import_file_enabled=true
      - NEO4J_apoc_import_file_use__neo4j__config=true
      - NEO4JLABS_PLUGINS=["apoc"]
      - NEO4J_dbms.security.procedures.unrestricted=apoc.*
      - NEO4J_dbms.security.procedures.allowlist=apoc.*
    volumes:
      - ./neo4j_data:/data
      - ./plugins:/plugins

This can


How can i refresh slices?

Hi ivan, i want to update my pie chart values? How can i do?

That's currently not supported!

Hi @editor83 ,
You can delete the subview chart dynamically on viewWillAppear and create it again....
override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(true)

        //remove subviews
        view.subviews.forEach({ $0.removeFromSuperview() })

        //label view
        label.text = "\(views!) views"
        view.addSubview(label)

        //add chart
        chartView = PieChart(frame: CGRect(x: 0, y: 0, width: UIScreen.main.bounds.width, height: UIScreen.main.bounds.height))
        chartView.delegate = self
        chartView.models = createModels()
        chartView.layers = [createCustomViewsLayer(), createTextLayer(), createTextWithLinesLayer()]
        view.addSubview(chartView)
        chartView.setNeedsDisplay()

    }

That's right. I forgot to mention this, thanks!
I was thinking on a clean transition where slides are animated from their current state to the new state. For now re-adding as described by @editor83 is the way to go.

Added a method clear() to PieChart which removes all the content from UI and models. To refresh now you can call clear() and re-add everything instead of re-adding PieChart.

There is no any method name clear()?


Refactor Popover

For making our components easier to use we have decided to remove the fixed close button inside the Popover component as there are other valid options for using an popover without "that" close button. The documentation serves as a guideline recommendation for the close button on certain types of content.
Actions

Remove fixed close button in Popover
Add story with example where said close button is used but composed from existing components
Update documentation to better reflect when to add a close button inside popover

@equinor/eds-ux Based on our discussion on removing fixed close icon inside Popover. Does this look ok? We'll have to make sure to adjust the documentation... 🤔

CHANGES:

Add Header sub-component, wrap for Title & Close Button.
Add Actions sub-component, wrap for Button.
Remove negative style values.
Move padding to sub-components.

todo:

[ ]  storybook description


Add topic "kokkos"

Please confirm this pull request meets the following requirements:

[x] I followed the contributing guidelines: https://github.com/github/explore/blob/main/CONTRIBUTING.md.
[x] I am not the sole author or employee of a company who created the topic or collection I'm changing.

Which change are you proposing?

[ ] Suggesting edits to an existing topic or collection
[x] Curating a new topic or collection
[ ] Something that does not neatly fit into the binary options above

Curating a new topic or collection

[x] I've formatted my changes as a new folder directory, named for the topic or collection as it appears in the URL on GitHub (e.g. https://github.com/topics/[NAME] or https://github.com/collections/[NAME])
[x] My folder contains a *.png image (if applicable) and index.md
[x] All required fields in my index.md conform to the Style Guide and API docs: https://github.com/github/explore/tree/main/docs

Kokkos is widely used in HPC projects and at the moment of writing there are already 58 public repositories matching this topic.

Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.

Force pushed to fix CI complaints. This should be good to go now.


Remove spaCy 3.0 deprecation warnings

This PR fixes https://github.com/RasaHQ/rasa/issues/8882.

I discovered some core tests that passed before and needed to be changed. Figured I should also add a test to make sure that we raise an appropriate error when the user forgets to add a model to their SpacyNLP config.

@jupyterjazz I think you got auto-assigned to this PR. On my end: it's no longer a work in progress so feel free to review. Also, feel free to pass it along to somebody else if you feel the auto-tagging system got it wrong.

@jupyterjazz I've incorporated your requests and they led to a better PR. Does it look good to merge now?


chore(package): some updates

@daddykotex Could you do a Rebase and merge instead of regular merge?

I will. I will rebase and merge when I have a second opinion and publish the new version.


Product Details using json content

Fix #114
🔗 Test URLs:

Before: https://main--caesars--hlxsites.hlx.page/caesars-palace/drafts/amol/hells-kitchen
After: https://issue-117-product-details--caesars--hlxsites.hlx.page/caesars-palace/drafts/amol/hells-kitchen

📝 Description:
Pulling from the new Excel to get json. Automatically creating sections based on the product details page and creating content structure to pass to already existing blocks and rendering them on the page. The page only has one block in it pointing to the product json endpoint
I have created three separate issues to build some other blocks at the top of the page that will be needed for product details. once those blocks are built, I will just have to pass the content from json and call those blocks in this code.
Please ignore the branch name it should be 114 to match the issue but it is not.

CLS issues. will take a look and get those in line before we move forward.

note to self-  move up the hero block to the top and let that render first. also add some CSS to not display if block is not loaded fully.


missing INSTALL.txt

This bug report was migrated from our old Bugzilla tracker.
Reported in version: 2.0.15
Reported for operating system, platform: Linux, x86_64
Comments on the original bug report:
On 2019-02-04 15:46:21 +0000, Professor Unbearable wrote:

A simple INSTALL.txt would be nice, like that which already exists in the SDL2 directory.
One potential issue that I would need help getting around in this file would be to find the target link libraries.
This is the error I get
~/SDL2_ttf-2.0.15 $ mkdir build; cd build
~/SDL2_ttf-2.0.15/build $ cmake ..
-- Configuring done
CMake Error at CMakeLists.txt:24 (add_library):
Target "SDL2_ttf" links to target "SDL2::SDL2" but the target was not
found.  Perhaps a find_package() call is missing for an IMPORTED target, or
an ALIAS target is missing?
CMake Error at CMakeLists.txt:24 (add_library):
Target "SDL2_ttf" links to target "Freetype::Freetype" but the target was
not found.  Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
-- Generating done
-- Build files have been written to: /home/profbear/SDL2_ttf-2.0.15/build

@madebr, is this fixed with your CMake changes?

The Freetype::Freetype target will be created: when using system libraries it will rely on FindFreetype for creating one.
When vendoring, it will create one itself.
No INSTALL.TXT is created though :)

Okay, great.


Fix transit stations and migration

Fix the migration so that instead of trying to replace an existing function, which would cause problems with the return type being unexpected in existing concurrent queries, a new function with a new name is created instead. This means we can just drop the old one once the migration and deploy are complete.
Also fixed a small bug - the new function supports relations, so the osm_id > 0 check was obsolete.
@rmarianski could you review, please?

:+1:


Adding release git tags

Hi - thanks for this amazing project! It's great to see and seems to work very well already.
I believe this is the accommodating PyPI package: https://pypi.org/project/dash-leaflet/
I noticed you are using versioning on PyPI, but not in your GitHub repo. For reproducibility - if you don't mind - would it be possible to add tags to the Git repo - so that we know which version of the code is released on PyPI?
I'm happy to contribute some GitHub Actions PR if that's something you would be interested in?

Thanks! Yes, that is the pypi package. During the last releases, i was actually starting to think along those lines, i.e. creating tags on git. Since the javascript source is not distributed as part of the python package, it is pretty tedious to tract changes with my current setup. Could you elaborate on what you mean by "contribute some GitHub Actions"? I haven't used GitHub Actions before, but from some quick googling it seems to have to do with automation.
My current build work-flow is simply,

Bump the version number manually in package.json, e.g. to 0.0.18
Build with npm: npm run build:all
Build pypi package: python setup.py sdist
Push to pypi: python3 -m twine upload dist/dash_leaflet-0.0.18.tar.gz

I would be happy for any suggestions for improvements, either in as a PR or as a comment.

Yes, GitHub Actions allow you to automate things - for example the release / deployment of your code - there are plenty of alternatives as well (e.g. CircleCI / TravisCI / etc). Instead of doing those steps "by hand", you could automate them.
For example on most of our projects, we tag the git repository when we want to do a release. We then push that tag to GitHub when launches a GitHub Action to build the code and deploy it. It's also a great way to add some basic testing.
In terms of your build workflow it could look something like this:

Bump the version number manually in package.json, e.g. to 0.0.18
Commit that change with git commit -a -m "Updating package.json to v0.0.18"
Tag the release with git tag -a v0.0.18 and then git push --tags
Let the GitHub Action do the build and release

I started with some example workflows here: https://github.com/r-chris/dash-leaflet/tree/master/.github/workflows
I seem to be missing some setup steps, though. Could you possibly point out some additional npm initialization that needs to happen when compiling from scratch?
On npm install I currently get:
  File ".../dash-leaflet/dash_leaflet/__init__.py", line 10, in <module>
    from ._imports_ import *
ModuleNotFoundError: No module named 'dash_leaflet._imports_'

Thanks! I have been working with CI before, but not GitHub Action. I'll take a deeper dive one of the coming days.
About the error, as far as i remember, it can just be ignored. After running npm install (and getting the error), you should be able to run npm run build:all.

ok, great - I think you are right even though that's not ideal for a CI workflow, because it'll just stop on that error - unless we force ignore that ... I'll give that a quick shot

I changed the PR from Draft to "ready" - feel free to play around with it!

I have now merged the pull request. I had to make one addition to make it work,

Add "pip install -r requirements" to the "python-publish.yml". Otherwise, the dash build process fails.

I had some issues triggering the publish job when pushing tags via cmd, but creating releases (and tags at the same time) using the GitHub browser GUI, everything seems to work. Thanks! Hence, i guess my new workflow will be,

Bump the version number manually in package.json, e.g. to 0.0.19
Commit that change with git commit -a -m "Updating package.json to v0.0.19"
Create a release (and a tag along with it) in the GitHub browser GUI.
Let the GitHub Action do the build and release

Let me know if you have other suggestions to improve the workflow :)

Great - you can also launch the GitHub Actions Workflow directly by pushing a tag, if you prefer that - then you won't have to manually create a "GitHub Release". I'll open another PR for you to see what that would look like.


Remove deprecated fields from plan file.

Remove deprecated fields, and code for handling/testing deprecated
fields.

Also made the plan file unmarshalling fail if any unknown field is
provided in the YAML file. This will prevent mis-configuration and also
let the user know when their plan file is outdated.

I am going to close this. We can tackle it in the future when we have a way to migrate old plan files to new ones. I don't think we should remove the fields until we have that migration path.


[1470] add mcb user show

Context
When debugging production problems it's handy to be able to view the user info in production without having to make a db connection.
Changes proposed in this pull request
Add commands to mcb:

mcb user list
mcb user show <id>
mcb user audit <id>

Checklist

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

 List users in mcb


Create ru_ru.json

Smol ru tanslate

QIO and Pump changed their names after 1.3.0, but you are still using the previous name here.

but you are still using the previous name here.
I just added new keys from the old translation.


Generators still create pass!

pass! was removed, need to update the generator to use the correct syntax.

Agreed, the generators in general need improvement.

Dupe


add combined summary file path on each individual summary xml file

We use the individual summary paths in the history section of the combined summaries page but one you are on a individual summary, a reader has no context to know which index in the collection they are or whether this individual post belongs to a combined summary.
From an app development perspective it'd be helpful to have a path to the combined summary it belongs to and the index of where it belongs in the history.

Closing this as it doesn't seem to be an issue anymore.


jsonContentOneOf do not provide correct types on handler

//code
[HTTPS_STATUS.OK]: jsonContentOneOf([
selectTaskSchema,
z.object({ message: z.string() }),
], "The selected task"),
},
export const single: RouteHandler<SingleTaskRoute, AppBindings> = async (c) => {
const { id } = c.req.valid("param");
const task = await db.query.taskTable.findFirst({
where: (task, { eq }) => eq(task.id, id),
});
if (!task) {
return c.json({ message: "Task not found" }, 200);
}
return c.json(task, 200);
};
I am getting type error on single handler
I know you did response it with different status code also i can do it
But I just want to know how oneOf schema  will work with handler properly
If I want to response with same status code but different json then how handler will infer the type

You can define a schema with .or from zod: https://zod.dev/?id=or

Cool! it's working perfectly. Thank you so much.
I have another questions.
When we should use
oneOf, anyOF
Or How?

Some good docs on this here: https://swagger.io/docs/specification/v3_0/data-models/oneof-anyof-allof-not/#difference-between-anyof-and-oneof
According to openapi you should prefer oneOf unless your responses can be a combination of things.
However, @hono/zod-openapi uses anyOf for all of the generated schemas - this is due to the underlying implementation of zod-to-openapi - you can see an issue here and an in progress PR here
All of the inferred types from @hono/zod-openapi  to hono really only work if using zod .or which in turn generates schemas with anyOf - if all of your API clients are just using hono rpc, this should be fine. If any of your clients are not hono rpc and are using some kind of openapi client generation, they could run into issues with endpoints that return anyOf in the schema.
Short answer - just use .or / anyOf if you are only using hono / hono rpc.


net: comment for constant not accurate

What version of Go are you using (go version)?

 go1.19.4 windows/amd64

Does this issue reproduce with the latest release?
Yes (sorry, this is a very insignificant issue, but I could not help it to raise it)
What operating system and processor architecture are you using (go env)?
go env Output
$ go env

What did you do?
https://cs.opensource.google/go/go/+/refs/tags/go1.19.4:src/net/dnsconfig.go
What did you expect to see?
attempts      int           // number of tries before giving up on a query

What did you see instead?
attempts      int           // lost packets before giving up on server

Want to send a patch?

attempts      int           // number of tries before giving up on a query

This is not true either.
https://github.com/golang/go/blob/f721fa3be9bb52524f97b409606f9423437535e8/src/net/dnsclient_unix.go#L273-L275
total attempts is equal to: len(servers) * attempts

Want to send a patch?

yes

update in : https://github.com/golang/go/pull/57806


Eliminate code duplication for containers/pods

Code duplication present in pod and container specific classes need to be removed, and moved to a common class.

@dinogun In the Docker use case, should we be suggesting requests? Right now it just gives 0.

Can you be more specific about which code is duplicated currently ?

@dinogun In the Docker use case, should we be suggesting requests? Right now it just gives 0.
Yes, we need to suggest requests in the docker case as well, and can become the basis of the initial yaml file.

The getters and setters in PodMetrics https://github.com/kruize/kruize/blob/ab41bd866aaae44f687cd96f67417d85c86cb899/src/main/java/com/kruize/metrics/PodMetrics.java#L39
and ContainerMetrics https://github.com/kruize/kruize/blob/ab41bd866aaae44f687cd96f67417d85c86cb899/src/main/java/com/kruize/metrics/ContainerMetrics.java#L28
Both PodRecommendations.java and ContainerRecommendations.java are identical


⚠ St. Lawrence Global Observatory CKAN has degraded performance

In 73c3ae8, St. Lawrence Global Observatory CKAN (https://catalogue.ogsl.ca/en/) experienced degraded performance:

HTTP code: 200
Response time: 14589 ms

Resolved: St. Lawrence Global Observatory CKAN performance has improved in b46390b after 5 minutes.


Update the expected binary size for big-endian platforms

Tested on AIX/ppc and Linux/s390x.

Thanks for the fix. Merged.


.case allows properties to be return that aren't in the declared initialState

interface Foo {
  bar: boolean
}

const INITIAL_STATE: Foo = {
  bar: true
}

const reducer = reducerWithInitialState(INITIAL_STATE).case(someAction, (state, payload) => {
  return {bar: true, SHOULDNT_ALLOW_THIS: true};
})

Following code typechecks, when SHOULDNT_ALLOW_THIS should throw a typecheck error.

I'm not the author of typescript-fsa-reducers, you should probably file this issue in its repo.

@aikoven whoops, sorry about that!


Fix check-spelling comments

Summary of the Pull Request
What is this about:
Fixes the comment references made by check-spelling
What is included in the PR:
Minimal changes to make sure that the comment stage uses the same configuration as the check pass
How does someone test / validate:
Create a PR in a repository against main, and then a PR in a repository against a branch with this fix
Baseline (main) https://github.com/check-spelling/PowerToys/pull/3#issuecomment-1019425721 has incorrect references to:
my @expect_files=qw('".github/actions/spelling/whitelist.txt"');
...
my $new_expect_file=".github/actions/spelling/expect.txt";

With this change (spell-check), https://github.com/check-spelling/PowerToys/pull/4#issuecomment-1019425784 has proper references to:
my @expect_files=qw('".github/actions/spell-check/expect.txt"');
...
my $new_expect_file=".github/actions/spell-check/expect.txt";

The paths are supposed to match the paths in the repository so that check-spelling will update its config files.
When I applied the changes to split the workflow, I missed copying over the config flag to this other job.
Quality Checklist

[ ] Linked issue: #xxx
[ ] Communication: I've discussed this with core contributors in the issue.
[ ] Tests: Added/updated and all pass
[ ] Installer: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Docs: Added/ updated
[ ] Binaries: Any new files are added to WXS / YML

[ ] No new binaries
[ ] YML for signing for new binaries
[ ] WXS for installer for new binaries

Contributor License Agreement (CLA)
A CLA must be signed. If not, go over here and sign the CLA.

@crutkas this should fix the issue that came up in the  Open Preview Handler for developer files PR


Linters

We need many different linters.

Style violations.
Common mistakes.
Bad idioms.
Potential performance problems.

The different linters can be developed independently of each other, and they are self-contained projects.
Core developers will help with the API and integration.

Do you want linters for the Lean or C++ code (or both)?
For the C++ code, it wouldn't be very difficult for me to add tools like clang-tidy and cppcheck to the build.
They could be triggered to only run when CMAKE_BUILD_TYPE=DEBUG, for example.
It has been a while since this issue was posted. If you're aware of any Lean targeted linters, I'd like to take a look.

mathlib has a linter framework: https://leanprover-community.github.io/mathlib_docs/commands.html#linting commands . Some of this should probably be incorporated into the core lean 4 distribution, but the details have not been worked out. (My impression is that the issue is primarily about Lean linters, as the C++ code is foundational and both user code and the elaborator itself are mostly written in lean.)

Let's close this issue now that the linter framework has been implemented, and reopen issues for specific linters.


Failed to install the update with error code: -18

Hello,
The plugin was working fine.
But after some reinstallation of the apps. I am getting the -18
I read the doc about it, but in my case I am getting this -18 all the time, I delete install, then open application close application, put it in background etc... always the same -18 :-(
Any idea how to debug that ?

On what platform you are getting this error: Android/iOS and what version? What plugin version you are using?

I found the problem with adb logcat :)
I was missing the chcp.json in the www directory.
The file was present on my server for  "hot update repository ". but not in the build www.

Great!


Only one video compression at one time

Hi,
As I could see VideoController class is Singleton. If I want to parallel compression of multiple video.
will it be fine if I use single instance for parallel compression?

It don't support concurrency working.

Do you have any plan to make it concurrent?

I'm afraid it maybe impossible currently, because the solution is based on encoder hardware, and the hardware is not allowed working concurrently.

Thanks for clarification.


[WIP] fixed pylint, formatted python files iwth cblack on localhost

Fixed linter check for indentation.
Fixes geohot/tinygrad/#198
using @Liamdoult and @gamwe6's suggestions.

Closes #198


Registration in repositories for package managers

Add chipmunk to:

pacman (arch, manjaro)
brew (mac)
chocolatey (windows)
apt (ubuntu, debian)
dnf (fedora)
YaST (opensuse, redhat)
dpkg (deepin)
etc.

This would be great.
For Linux systems I would suggest going in cross-distribution package managers like Flatpak, Snap, Linuxbrew and Nix package manger, since they are available on every Linux distribution nowadays and they are easier to package

@AmmarAbouZor thanks for your suggestion... it really makes sense. We should start with this issue pretty soon. At the moment we are in a state of research of the most optimal way to organize it in a somehow automatic way.

@DmitryAstafyev I think it can be added to the release GitHub action. For Snaps there is already GitHub Actions for that. The Neovide Project has it built in their release Action.
For Flatpak (Main store is Flathub) and Nix it's possible to add them to the release action too since each publish consists of CLI commands.

For winget (and initially chocolatey) I found this blog post which is old enough to be possibly outdated, so I checked actual repository of the project and found out that there still is winget github action, but nothing for chocolatey: developing of the tool referenced in the blog post stopped.
There is however another project which managed to automate chocolatey, its latest release was 5 days ago and already in chocolatey. They also bothered to write a blog post about that too.
Have not found anything conclusive for scoop though.

We will organize/manage distribution on a standalone repo: https://github.com/esrlabs/chipmunk-distribution to make it easier maintain

issue can be closed as soon as we have now: https://github.com/esrlabs/chipmunk-distribution ... all issues related to package managers should be addressed there


Rename README.md to fix build issues on docs.rs

Version 0.2.0 wouldn't build on docs.rs due to include_str!("../README.md") failing because here the readme was called readme.md
This should fix the issues.

@gensmusic - I really want to use this library since it looks awesome, but I can't currently since it fails to compile on case-sensitive file systems. I would love it if this could get merged and released!


Fix OpenCover 4.6.519 compatibility

Argument -filter needed the double quotes to be escaped

Look good to me.


Remove duplicate logic after upgrading cordova-common

Current coverage is 76.85% (diff: 100%)

Merging #223 into master will decrease coverage by 0.11%

@@             master       #223   diff @@
==========================================
  Files            16         16
  Lines          2232       2221    -11
  Methods         415        412     -3
  Messages          0          0
  Branches        442        439     -3
==========================================
- Hits           1718       1707    -11
  Misses          514        514
  Partials          0          0

Powered by Codecov. Last update a0c0eda...16167f5

LGTM 👍


tflite

How can we convert this model into .h5 or savedmodel or tflite?

Hi,
The model is stored in the "model" attribute of the RetinaFace object, so you can try something like this :
detector = RetinaFace(FLAGS.weights_path, FLAGS.use_gpu_nms, FLAGS.nms_thresh) model = detector.model model.save_weights("path_to_file.h5")
Let me know if it works

AttributeError: 'Function' object has no attribute 'save_weights'

Ok try this code (taken from from retinaface.py):
from networks.retinaface_network import RetinaFaceNetwork
model = RetinaFaceNetwork(model_weights).model
model.save_weights("path_to_file.h5")

This code saved the model in .h5 format (I named it "rf.h5"). But after trying to load the model using the following code, I received an error.
loaded_model_from_h5 = tf.keras.models.load_model('rf.h5')
raise ValueError('No model found in config file.')
ValueError: No model found in config file.

Yes I think this is the issue, try using model.save() instead of save_weights()
Sorry I dont have my laptop so I cant test myself at the moment


[ios] bring back channel and completed completion params to showShareSheet()

Good call, after digging in more it looks like completion block is the recommended format. Opened a corresponding PR here: https://github.com/BranchMetrics/ios-branch-deep-linking/pull/389


Add ArrowToParquetSchemaConverter, deprecate arrow_to_parquet_schema

Which issue does this PR close?

Part of https://github.com/apache/arrow-rs/issues/1938

Rationale for this change
While working on the upgrade to arrow 54 in DataFusion https://github.com/apache/datafusion/pull/13663   I found it was not clear what the coerce_types argument in arrow_to_parquet_schema meant or what value to pick to keep the existing behavior.
I had to go digging on https://github.com/apache/arrow-rs/pull/6313 to find what the default / old behavior was (true or false)
Turns out the answer is
    let schema_desc = arrow_to_parquet_schema(&schema, false)?;

It is clearly documented on WriterProperties but not on the lower level apis
Thus I would like to propose making a new API for converting schemas where the defaults are clearer and deprecate arrow_to_parquet_schema (and revert the unnecessary breaking API change)
What changes are included in this PR?

Add ArrowToParquetSchemaConverter,
Lots of comments / examples
Revert the changes to arrow_to_parquet_schema made in https://github.com/apache/arrow-rs/pull/6313
Deprecate arrow_to_parquet_schema with a clear message about what to use instread

Are there any user-facing changes?
A new API and a deprecation of an existing one

@alamb could you take a look at #6828? Some of the doc changes will conflict, at least. +1 on the idea, though 😄

Just the doc CI failure to fix. Otherwise looks ready to go (mod capitalization which can be a follow on 😉). Thanks again @alamb.

Thank you 🙏
I fixed a few more capitalization inconsistencies and added a link to the date section of the parquet spec too

I did wonder if this should instead be an options struct that gets passed to a method (or has a member function that accepts the actual schema). This would allow using the same config for multiple files, and is perhaps more consistent with other APIs?

I agree, as there is no state held in the converter there is no reason for it to be a consuming builder. I made this change in 0ab4eb4ccc

Thanks again @etseidl  and @tustvold


Added docs for both downto, updated arg name for style reasons. #12467

Update the iterator's related var name for consistency.
Did this because it only had bare signature for docs, and the to argument reads badly.

Could you leave the parameter renaming out of this PR and just add the docs for now? I think that change might need some more discussion first.

You can probably make to an external parameter name and limit the internal one to get the best of both worlds.

The last commit doesn't touch the code but I think it highlights why I feel the name change is better. Compare this:

Get an iterator for counting down from self to to

with this:
Get an iterator for counting down from self to limit
Read it out loud and it's really obvious (to my ear).

You can probably make to an external parameter name and limit the internal one to get the best of both worlds.

Method arguments gives the 2nd reason for using named parameters as…

The second use case is making a method parameter more readable inside a method body

but I'm more concerned with how the documentation reads, I'd rather that limit were the external argument.
From the issue

It's not a huge improvement

Perhaps I'm bikeshedding but my view is that code can be made to sound more like English but will always hit a limit somewhere and read like code (that's why it's called code, after all) but the documentation is English and thus any possibility to make it flow better is a win.

This should also be discussed together with Int#upto

Agreed. How about we keep this docs only, I'll push up docs only for upto as I now notice that has no docs, and that'll close this and the linked issue and I'll open a new one to keep the discussion in one place?
I just noticed that trailing semicolon, I'll fix that now too.

But giving different external and internal parameter names doesn't imply that the docs must use the former. In fact this is done by Steppable already:

def step(*, to limit = nil, by step, exclusive : Bool = false, &) : Nil
Iterates from self to limit incrementing by the amount of step on each iteration. If exclusive is true, limit is excluded from the iteration.

I would always prefer renaming local vars over changing an API (changing a message signature). The scope of the instance vars is limited by being part of a very short interface, so it's also not a dangerous change IMO.
I now see that the current naming convention extends throughout the file and I'm getting confused with my own "fixup" commits so I'll stick to add the docs only and leave the code for another day.


Add the thestocks.im

http://thestocks.im/

The best royalty free stock photos are delivered now along with videos, audios, icons, fonts and colors.

Was already done by https://github.com/neutraltone/awesome-stock-resources/pull/86