PureScript and Haskell conflict

The title refers to this: https://github.com/neurocyte/zat/blob/10de00d68414ef4729e69a2e779c891aa2273368/src/file_types.zig#L214-L219
Hi 👋, I'm the maintainer of PureScript TS grammar. It started as a fork of Haskell's grammar and its C scanner was mostly left untouched (due to me not knowing C).
Indeed if I uncomment this filetype and try to build zat I'm getting:
└─ install zat
   └─ zig build-exe zat ReleaseSmall native 1 errors
error: ld.lld: duplicate symbol: state_new
    note: defined at scanner.c
    note:            /tmp/zat/zig-cache/o/2f3c88c48c0e525bd29533e3aac02ab0/scanner.o:(state_new) in archive /tmp/zat/zig-cache/o/ac7b81e2c1f5d0f85b023adfbed9accb/libtree-sitter.a
    note: defined at scanner.c
    note:            /tmp/zat/zig-cache/o/2b99987fca3759990739259e47c5877a/scanner.o:(.text+0x0) in archive /tmp/zat/zig-cache/o/ac7b81e2c1f5d0f85b023adfbed9accb/libtree-sitter.a

I would be very grateful if you could brief me on what is the issue and/or direct me towards what I could do on my end to resolve this incompatibility. I think I fixed it

I think I fixed it in https://github.com/postsolar/tree-sitter-purescript/commit/08cdbb85eeaab317701bc797770a2c1a65e43ffe, it now works for me (I tested it by updating https://github.com/neurocyte/tree-sitter on my fork and building with this updated dependency).
So I believe if you update tree-sitter and its dep here it should work. I'll issue a follow-up PR to enable PureScript.

Good to know that the purescript/haskell conflict is resolved. I will merge your PR after updating.
Note that both haskell and purescript parsers apparently have sanitizer bugs so I will also disable the sanitizer in tree-sitter first. (zig enables it by default unlike clang)


Packages for conan

Hi Roland!
I am trying to package the sqlpp11 suite for conan, as it has been requested by some users: https://ci.appveyor.com/project/rbock/sqlpp11-connector-sqlite3/history
So far I have succesfully done:

https://www.conan.io/source/sqlpp11/0.38/memsharded/testing
https://www.conan.io/source/date/1.0.0/memsharded/testing

But when got to the connectors, I am having problems building them, both stl (https://www.conan.io/source/sqlpp11-stl/0.4/memsharded/testing, not working) and sqlite3. First, I guess that VS is still not supported for the connectors, tried with latest VS2015Upd2, with build errors. First was easily removed adding <functional> header, but then some std::get issues. Also checked your own appveyor: https://ci.appveyor.com/project/rbock/sqlpp11-connector-sqlite3/history
Also got some build errors for Ubuntu with gcc5.3, last commit in connector-stl seems like one year ago, wondering about the status too (though likely could be my bad here)
Just wanted to offer my help, as I usually deal with CI and generating multiple configurations for some packages, check for example how I generating almost 100 different binaries for ZeroMQ, with just this  repo: https://github.com/memsharded/conan-zmq. If you think that conan might help to connect the different libraries together, please tell me and I'd love to collaborate on this task.

Hi James,
Thanks for your message! I definitely could use some help with the CI integration, especially with appveyor.
As you can see, the develop branch of sqlpp11 is currently failing. I need to fix that first (or you give it a try; it is one of those variadic template problems of MSVC). I'll to get to that over the weekend.
Once that is done, I would suggest starting off on the appveyor branches of the mysql and sqlite3 connector. I've some work there already. The mysql connector compiles but does not link.
The STL connector is an experimental proof of concept, that is not used anywhere yet (I'd be very surprised to learn otherwise). It needs major adjustments, which I hopefully get done some time in July. Whether there is a chance to get this to compile with MSVC, I can't tell.
There are also the postgresql and the OBDC connectors which not maintained by me.
I have to admit, I do not know so much about conan yet. But the idea of a C++ package manager that helps installing sqlpp11 and connector libraries sounds appealing :-)
Best,
Roland

Hi Roland!
Perfect. This weekend, it will be impossible, but from next Tuesday, I will have some time. If you are able to fix that variadic template in MSVC this weekend, please tell me about the status.
I will probably start with my fork of sqlpp11, so I can just create the package directly after the CI, so it will be much easier to consume from the connectors CI too. I'd say to start with the most mature connector, if it is mysql, that one.
Tagging the repo would be very useful, as it would be very time consuming for me to debug and fix library or tests compiler errors. But if you are able to build it locally in your machine, setting up things and travis/appveyor CI, I can help there easily and quickly. So when you are good that a certain version works in VS, it would be nice if you tag it, so I can easily refer to it.
Cheers!

Hi James,
I just created new releases of sqlpp11 and the connectors for mysql and sqlite3. Everything is fine on travis (Linux und OSX). There is trouble with the connector libraries on appveyor:

sqlpp11 works fine with MSVC 2015 Update 2.
The mysql connector compiles but does not link
sqlite3 connector compiles and links (but with conflicts). Tests seem to run forever.

Seems to me like dependency problems and therefore potentially perfect for conan from what I understand.
Best,
Roland

Ok, 0.39 I see, perfect. Tomorrow I'll be busy, but on Tuesday I will resume this task. Talk to you then, thanks! Cheers.

Hi! Today I have started with it. For packaging sqlpp11 after running the tests, it is very easy. I also managed to get the dependencies to "date" and "boost" in windows, very easily with conan, and maintaining the build with and without conan, so it might help. I wanted to try also the mysql connector, and as there is https://github.com/conan-io/wishlist/issues/22 also open. I am trying to get it running on Windows. No sucess so far. I'll keep reporting my progress. Cheers!

It seems we have a problem with Mysqlclient (connector/C) in Win. It doesnt build with VS14, it requires VS12. While sqlpp11 requires VS14 (I guess the same for mysql connector). I keep investigating, but seems difficult to solve until the mysql source code builds with VS2015. Any idea on this?

Nop, so far mysqlclient has no dependencies, and I have been able to build it with VS12 relatively easily. It is C, and it should be ABI compatible with VS2015, but the problem is that the API contains the incompatible bits, they are in the headers, so I cannot link against it from VS2015, cause I get build errors from those headers. I have found this thread http://forums.mysql.com/read.php?117,634127,634127, which seems that for 5.7 they did something, though the info is contradictory. I have tried to workaround it in the build, adding defines as HAVE_STRUCT_TIMESPEC, but no success. So the bottleneck here seems MySql VS15 incompatibility, not really a dependency management problem. Will fight a bit more with it :)

I have been able to build mysqlclient with VS12, then link it from VS14. Actually if #including only "mysql.h", it doesn't use the incompatible API, and it seems your code only depend on that main header. A bit tricky yet, with runtime (MT, MD) and shared/static, but seems workaround-able :)
Some details here: https://github.com/conan-io/wishlist/issues/22#issuecomment-227899419
So first, we will try to stabilize first this package, then I will resume with the mysql connector.

Nice! Thanks for the good news :-)
I'll look at the details in a few days (I am buried in other work these days).

Don't worry, now in https://github.com/hklabbers/conan-mysqlclient/pull/1 it seems that we have some minimal support for Mysqlclient in several OSs, will check if possible to build the sqlpp11 connector with it asap.

That looks quite promising indeed. Looking forward to further news on that!

Hi! I have tried to build connector-mysql in Win MSVC14, against the https://github.com/hklabbers/conan-mysqlclient package. I am having the following build error:
C:\Users\memsharded\.conan\data\date\1.0.0\memsharded\testing\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\include\date.h(971): error C2668: 'date::floor': ambiguous call to overloade d function [C:\Users\memsharded\.conan\data\sqlpp11_mysql\0.18\memsharded\testing\build\39792f9d7b6bb6b2a4a809a517844bd5869d662d\src\sqlpp-mysql.vcxproj]
  C:\Users\memsharded\.conan\data\date\1.0.0\memsharded\testing\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\include\date.h(895): note: could be 'To date::floor<To,__int64,std::micro>
  (const std::chrono::duration<__int64,std::micro> &)'
          with
          [
              To=date::days
          ]
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\chrono(595): note: or       'std::chrono::duration<int,std::ratio<86400,1>> std::chrono::floor<To,__int64,std::micro>(
  const std::chrono::duration<__int64,std::micro> &)' [found using argument-dependent lookup]
          with
          [
              To=date::days
          ]
  C:\Users\memsharded\.conan\data\date\1.0.0\memsharded\testing\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\include\date.h(971): note: while trying to match the argument list '(std::
  chrono::microseconds)'
  C:\Users\memsharded\.conan\data\sqlpp11_mysql\0.18\memsharded\testing\build\39792f9d7b6bb6b2a4a809a517844bd5869d662d\src\prepared_statement.cpp(148): note: see reference to function tem
  plate instantiation 'std::chrono::time_point<std::chrono::system_clock,date::days> date::floor<date::days,std::chrono::system_clock,std::chrono::microseconds>(const std::chrono::tim
  e_point<std::chrono::system_clock,std::chrono::microseconds> &)' being compiled
  char_result.cpp

I am using the tags 0.39 and 0.18 for sqlpp11 and sqlpp11-connector-mysql. Any idea about this build error? Thanks!

Hi,
Given that the code specifies ::date::floor I have no idea why MSVC sees any ambiguity. Weird...
Please try to replace ::date::floor with ::sqlpp::chrono::floor. That should take care of it.
Best,
Roland

Yes, that fixes the build error, now I am getting some link errors, investigating.
Maybe it is a good idea to open the 0.39 branch instead of tag? May I submit a PR with this change to this branch? Thanks!

Sure, a PR would be great :-)

Good, I'd just need that you create the branches from the tags, so I can do the PRs to the respective branches.

You can just use the develop branch for that.

Hi James,
I just pushed a release for sqlpp11 and the mysql/sqlite3 connectors. The connectors contain the floor change.
Best,
Roland

Hi James,
The sqlite3 stuff works for sqlite3 by now.
I am still having trouble with mysql though. The connector library is incompatible with MSVC-2015 (and cannot even be compiled). I am using the mariadb connector for compiling now. This works fine.
However, the tests fail for some reason I cannot figure out.
Cheers,
Roland

Hi James,
Is sqlpp11 still on your radar? As far as I can tell, MSVC has made some progress (although I also received disturbing reports about the 2017 preview).
Best,
Roland

Hi Roland,
Sorry for taking so long, conan is growing fast and really demanding on the core codebase, so we couldn't keep track on packages like this. I think in this sprint (will be smaller than previous ones, were huge) I could give it a spin and check current status. I'll let you know how it goes.
Cheers!

As far as I can tell, the MSVC issues are resolved.
I am closing this ticket as being outdated.
Please feel free to open new ones(s), of course.


Any one considering adding a search button?  CTRL+F in browsers don't seem to allow searching

It would be nice to have search capabilities
Ticket #36929

not support this

Its a know limitation due to usage of canvas for the implementing the spreadsheet interface. https://html.spec.whatwg.org/multipage/canvas.html#best-practices


Failed to load class "org.slf4j.impl.StaticLoggerBinder"

I am testing the library and it works just fine in dev, but when I run my jar I get this:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

Should slf4j dependencies (below) be added manually in order to work out?
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>${version}</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-simple</artifactId>
    <version>${version}</version>
</dependency>

Thanks!

Due to this conflict (warning)
[WARNING] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Dependencies with duplicate files detected. The dependencies [ch.qos.logback:logback-classic::jar:1.2.10[paths: /home/me/.m2/repository/ch/qos/logback/logback-classic/1.2.10/logback-classic-1.2.10.jar;], org.jboss.slf4j:slf4j-jboss-logmanager::jar:1.1.0.Final[paths: /home/me/.m2/repository/org/jboss/slf4j/slf4j-jboss-logmanager/1.1.0.Final/slf4j-jboss-logmanager-1.1.0.Final.jar;]] contain duplicate files, e.g. org/slf4j/impl/StaticMDCBinder.class
I had added this exclusion
<dependency>
      <groupId>io.quarkiverse.logging.logback</groupId>
      <artifactId>quarkus-logging-logback</artifactId>
      <version>0.10.0</version>
      <exclusions>
        <exclusion>
          <groupId>org.jboss.slf4j</groupId>
          <artifactId>slf4j-jboss-logmanager</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

and apparently it was good. In fact, It works just fine in DEV mode only. When I run the uber-jar it does not work as expected and throws the exception below
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

If I remove the exception above the LOGBACK works, but the WARNING duplicate is back.
I'll have to live with this warning if I want to use logback in prod.

Do you have a reproducer?

yes, would you mind take a look at? it's here: https://github.com/efranca/quarkus-logback-demo

Hi, any workaround for this, please?
I reproduce this with:

quarkus-logging-logback 0.4.0
quarkus 2.2.0


Flow Router Support

Could we get support for flow-router as well?

@hpx7 yes. It's already been discussed internally as an upcoming feature.

+1

so i guess there is okgrow will not work with flow router?

@thirdchance57 - Not exactly sure what the comment means, but feel free to check the pending PR here: https://github.com/okgrow/analytics/pull/37

The most recent update has support for flow router. There is also an example app included in the repo under the examples folder.

@tsemana better add it to the readme! :) Aside from the example and the commit message I wouldn't have figured out that there's flow router support.

Sorry, one more question. I'm trying to get this to run with Flow-Router. When debugging, I can see all the events I manually track with analytics.track(), but Flow routing changes don't seem to trigger anything.
Did I miss a step? It seems in the example you're not doing anything special to get it to run automatically with flow router...


refactored sendSms node. use axios instead of twilio npm module

hey @cabullmann  or @ebibergall ,
I refactored the Twilio Extension so that it does not use the huge NPM module anymore but their HTTP API only. This makes it way faster and smaller for virtual agents. Could one of you please double check if it still works perfectly? In my tests, everything is working well.
Thanks


perf: minify

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

46 of 46 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 99.332%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
346

Relevant Lines:
346

💛  - Coveralls


feat: remove retry limit from erc20 transfers

Related Github tickets

https://github.com/VolumeFi/paloma/issues/1050
https://github.com/VolumeFi/paloma/issues/1802

Background
This change will make sure that ERC20 transfers are being retried continuously instead of stopping after 2 retries to try and attempt to prevent a deadlock. There might still be a need for a manual unlock down the road.
Additionally, we now make sure to stop processing skyway messages while we have an ongoing contract deployment, to avoid a desync of the nonces on the old and new compass.
Testing completed

[ ] test coverage exists or has been added/updated
[ ] tested in a private testnet

Breaking changes

[ ] I have checked my code for breaking changes
[ ] If there are breaking changes, there is a supporting migration.

I ultimately decided against the watch dog approach, since we're lacking access to a lot of dynamic information at the EndBlocker, that is naturally available during the attestation process. So instead, we just keep brute forcing the message.

@byte-bandit needs a signed commit to merge.


Copilot chat cleanup - removing Vite and updating README

Motivation and Context

Removing Vite dependency to simplify toolchain + updating README
Description

We are authenticating with the /common endpoint, and in order to use /common/ endpoint, the application must not be configured with 'Consumer' as the user audience. The userAudience should be configured with 'All' to use /common/ endpoint.
Contribution Checklist

[X] The code builds clean without any errors or warnings
[X] The PR follows SK Contribution Guidelines (https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
[X] The code follows the .NET coding conventions (https://learn.microsoft.com/dotnet/csharp/fundamentals/coding-style/coding-conventions) verified with dotnet format
[X] All unit tests pass, and I have added new tests where possible
[X] I didn't break anyone :smile:

@adrianwyatt waiting on for a feature description for Shannon to update README (but non-blocking, we can update it in a later PR)


Restored UML diagram

Updated to spec version 1.0.0
Related Issue(s): #1030
Proposed Changes:

Updated to spec version 1.0.0

PR Checklist:

[x] This PR is made against the dev branch (all proposed changes except releases should be against dev, not master).
[x] This PR has no breaking changes.
[ ] I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.
[ ] This PR affects the STAC API spec, and I have opened issue/PR #XXX to track the change.

@hgs-msmith - one of the changes we made in 1.0.0-rc.1 is that collection no longer inherits from catalog. Could you update the UML so it doesn't have that relationship?

After the mtg this morning, it dawned on me what the problem is and what the relation is:

Catalog and Collection have a has-a relationship -- a Catalog has-a zero-or-more Collections.
Collection is NOT a Catalog (is-a)
Collection and Catalog both is-a (are-a?) "STAC Aggregate" -- they both relate together other object (a Collection relates together other Collections and Items; a Catalog relates together other Catalogs, Collections, and Items). Aggregate is probably a bad term to use here b/c it's too easy to get confused with SQL-like aggregation functions instead of having the domain-driven design meaning.
I think it's actually simpler just to say they're two types not related by subtying, but happen to have several fields that are named the same.

Updated UML diagram to remove inheritance relationship between Collection and Catalog.


DialogRef and ModalComponent improvements

Changed the return type of the functions beforeDismiss and beforeClose of ModalComponent to be a boolean or a promise that resolves to a boolean. This is useful when using a modal if another one can be closed. (Since now  can be returned the result of the second modal)
In DialogRef updated close() dismiss() and _fireHook to use Promises.
Changed contentRef to a property and added contentRefPromise getter to return a promise that resolves when the contentRef is set. This is useful since when a new modal is created, the resolved dialogRef does not have the contentRef set yet.
Eg:
modal.confirm().open().then(dialog => {
      console.log(dialog.contentRef); // This prints undefined
});

Using contentRefPromise:
modal.confirm().open().then(dialog => {
      dialog.contentRefPromise.then(cref => {
          console.log(cref); // Here it is set
      });
});

I'm not sure about the name contentRefPromise, if you have a better one I can change it.

I'll sync the changes you have done so it can be easly merged.

Removed the conflicts.

Hi @CaselIT
Thanks for the PRs.
I didn't have the time to look over them but from a quick overview I couldn't understand what is the intent.
Also, it's best to open an issue before posting an API changing PR, discuss about it and decide the best action.

Another thing I think is a good practice is to post PR's with a minimum set of functionality.
For example, a PR for beforeDismiss  and beforeClose and a different one for the other change.
It's hard to get into someone's logic and intent when the change is big.
This is just a suggestion of course.

:+1:
It' just that I've been using this library and found these two changes useful.

I couldn't understand what is the intent.

Regarding which part?
Regarding the api, this pr is backward compatible with the older api

@shlomiassaf Have you had a chance to look at the pr?

Would you prefer if I opened two different issue?

I've removed the contentRefPromise

@CaselIT Thanks for the PR.
I will push a commit later with some general clean up to the DialogRef.
Some of that is old code I wrote which isn't ideal.
I did one change in your commit, I explicitly set a .catch call instead of .then(fn, catchFn) since it's the best practice in promises...

I did one change in your commit, I explicitly set a .catch call instead of .then(fn, catchFn) since it's the best practice in promises...

I did not know it. You never stop learning.
Thank you @shlomiassaf for this library :wink:


cmd/scollector: add a kill switch for total memory used by scollector

This should help prevent memory leaks in CGO or WMI from causing scollector to consume too much memory.

very nice. LGTM

This only works if the process monitoring collectors are enabled, but it matches based on the os.Getpid call, so I don't think you need to be explicitly monitoring scollector.
I'm going to manually deploy this to a few systems including ny-bosun01 (largest scollector memory usage on linux in our environment) to make sure there aren't any issues. Can then merge it on Monday.

So it appears we don't log panics on Windows so I changed the error from a panic to a fatal. I also added #1867 to find a way to log panics.

^ was just a rebase and a missing multiplier:

Merging to master after travisci builds


Bump the version to 0.1.2

Why? So that we can use the updated version in our app, since it can't reference gems on github directly.

👍


Dropdown menu: Use no-auto-focus

In Daylight we want to use no-auto-focus on dropdown contents in order to not have the page move around with auto-opening dropdowns. I noticed that noAutoFocus isn't actually respected with dropdown-menu. This seems to be because dropdown-menu shouldn't use the DropdownContentMixin auto focusing behaviour, and instead uses the menu focus behaviour.
If we don't actually want this, I can remove the auto-opening on the dropdown menu demo in Daylight.

I'll be opening a fresh PR with the change Dave suggested


Thieving gloves don't function.

Description

They simply don't do anything. People can see the do-after and also see the item transferring to your hand.
Edit: all they do is hide the text popup, which seems kind of pointless

they half the doafter duration
common tactic is to drink something while doing it so it doesnt look to sus, no popup and its fast so victim is none the wiser

when an item is useful in essentially one location (the bar next to the counter) it probably needs a fix

Didn't it use to hide all interactions, the item visibly being transferred to your sprite, the doafter...?

Didn't it use to hide all interactions, the item visibly being transferred to your sprite, the doafter...?

nah I’m pretty sure it’s always been broken

the main thing that a person doesn't see
Urist McGreytide trying to take off your captain's PDA

Even if it wasn't originally intended to work that way, the gloves hiding the progress bar/item move animation makes sense.


Ron new extension for openldap testing

Issue: openldap testing
Problem
no existing go framework code to test openldap
Solution
created extension for opeldap; openldapauth.go and openldapauth_test.go
Testing
run test suite - output should indicate openldap enabled; user logged in; openldap disabled; user login failed
Engineering Testing
Manual Testing
running test
Automated Testing

Test types added/modified:

Validation (Go Framework)

If "None" - Reason: EXPLAIN THE REASON

If "None" - GH Issue/PR: LINK TO GH ISSUE/PR TO ADD TESTS

Summary: TODO
QA Testing Considerations

Regressions Considerations

TODO
Existing / newly added automated tests that provide evidence there are no regressions:

TODO

should be 2.6 branch


Replace move() with std::move()

Replace move() with std::move() for Velox coding style and best practices

@leoluan2009 This is a nice change, but I wonder how did this compile before. Do we have "using namespace std;" somewhere in a header file?

Yes, https://github.com/facebookincubator/velox/blob/main/velox/common/process/StackTrace.cpp#L42 and https://github.com/facebookincubator/velox/blob/main/velox/common/process/ProcessBase.cpp#L39

@leoluan2009 Thanks. Would you send a follow-up PR to remove "using namespace std;"?

@leoluan2009 Thanks. Would you send a follow-up PR to remove "using namespace std;"?

@mbasmanova  Yes, I will submit a follow-up PR.


Possible Internalize regression

Good day!
It seems that there's a regression in v2.0.29 with internalize. Simply setting the --internalize flag triggers an error "Input file not found: --internalize"
Based on the recent commits, I believe the idea was to add an optional list of files with the flags, but it might not work now when no files are provided at all

Seems they are public from 2.0.24. At least that is the version I tested. 2.0.18 was still internal.

OK will look into internalizing Cecil, sorry about all the regressions

Filed #358 to track it separately

Published 2.0.30, please try it out:
https://www.nuget.org/packages/ILRepack/2.0.30
https://www.nuget.org/packages/ILRepack.Lib/2.0.30


Demonstration Data State Vector

Hi, may I ask what each element in the demo data state vector of the observation represents? Specifically, we are interested in the EE positions and poses in the trajectory. Thanks.

https://github.com/haosulab/ManiSkill/blob/893cc416bfc92cf334c7e7cc23c709656ed39cc6/mani_skill/agent/agent.py#L213
This is the state (or agent state) for the robot agent provided in the demonstrations. It consists of ee_pos, ee_vel, qpos, qvel, and miscellaneous controller states.


Fixed #14645 -- Combined queries for using exclude with multiple conditions.

Ticket: #14645

Closing due to inactivity.


Issue to update a local pack ?

trying this:
> cpackget.exe pack add C:/Packs/STMicroelectronics.STM32U5xx_DFP.0.1.1.pack
I: Using pack root: "C:\CMSIS_PACKS"
E: The pack's pdsc (C:\CMSIS_PACKS\.Local\STMicroelectronics.STM32U5xx_DFP.pdsc) has no release tag matching version "0.1.1"
E: pack version not found in the pdsc file

I have this in my local pack's pdsc:
<releases>
	<release version="0.1.0-alpha1" date="2022-03-09">Add U5_GFX and U5_4M devices</release>
	<release version="0.0.1" date="2021-03-01">Initial release of STM32U5 Device Family Pack.</release>
</releases>

Hi @fred-r , shouldn't there be a 0.1.1 version on your pdsc file? I only see 0.1.0-alpha1 and 0.0.1.

Yes, that's the content of the local pack's pdsc, but the content of the .pack's pdsc is like this:
  <releases>
    <release version="0.1.1" date="2022-03-17">
      Add component for TIMER code generation
    </release>
    <release version="0.1.0-alpha1" date="2022-03-08">
      Add condition for devices supporting GFX
    </release>
    <release version="0.0.1-alpha1" date="2022-03-01">
      Initial release with HAL/LL drivers
    </release>
  </releases>

Looks like the local one takes precedence over the one I try to install.

cpackget.exe pack add C:/Packs/STMicroelectronics.STM32U5xx_DFP.0.1.1.pack

I am struggling to understand the discussion.
My expectation with the above command is, that the pack gets installed into
c:\CMSIS_PACKS\STMicroelectronics\STM32U5xx_DFP\0.1.1
If that folder already exists, then the version is already installed.
On local packs (packs which are not public = in .Web folder but in .Local) we should not have strict versioning expectations, especially if the  tag is not set or cannot be reached. This pdsc may not contain the version in the release history.
In this case a local pack file is referenced, therefore we do not need to find out where to download it from.
If the version installed is higher than what was previously installed you should replace the pdsc file in .Local with the pdsc from the most recently installed pack (to be discussed).

Indeed:

initially, I had a local pack for this U5 DFP: 0.1.0-alpha1
then I wanted to install a .pack with a higher version (0.1.1)

cpackget rejected the installation saying the version does not exist in my pdsc.
To make it work, I removed the reference to the local pack in "local_repository.pidx".
So, I think that cpackget parsed the pdsc from the .Local instead of parsing the pdsc from the .pack I was trying to install.

@fred-r  I actually missed the fact that you referred to a "local_repository.pidx" when you wrote "Local Pack".
It does not change the fact that cpackget should always install a pack which is referenced from the file system.
Even if the same version (or other versions) are listed in the local_repository.pidx. If the same pack version is installed and also available as a local_repository entry, the local_repository entry will take precedence and the installed pack version being ignored.

Hi @fred-r, @jkrech I confirmed that in the code.
Cpackget hasn't yet extracted the current pack's pdsc file when checking if the version is present in an existing pdsc file.
Let me fix that

Hi @chaws , I don't see the purpose of checking for the version you want to install needing to be in an existing pdsc file?
What am I missing? Are you looking for an inconcistency between the version the filename is suggesting and the contained pdsc file you are going to extract into the installation folder?

@jkrech this is a sanity check/assertion: the version you're trying to install via pack file should be present in the pack's pdsc file. The issue here is that cpackget is using an old pdsc file for the validation.

cpackget.exe pack add C:/Packs/STMicroelectronics.STM32U5xx_Drivers.0.1.2.pack
I: Using pack root: "C:\CMSIS_PACKS"
E: The pack's pdsc (C:\CMSIS_PACKS.Local\STMicroelectronics.STM32U5xx_Drivers.pdsc) has no release tag matching version "0.1.2"
E: pack version not found in the pdsc file

In fact I really need to clean the .Local, updating local_repository.pidx did not work finally.


Cannot read property '[object Array]' of undefined

Hi
PS D:\Lotus\LotusWin> electron-icon-maker -i icon_build/icon.png -o icon/
{ i: 'icon_build/icon.png',
input: 'icon_build/icon.png',
o: 'icon/',
output: 'icon/' }
Created D:\Lotus\LotusWin\icon/icons/png/16.png
Created D:\Lotus\LotusWin\icon/icons/png/24.png
Created D:\Lotus\LotusWin\icon/icons/png/32.png
Created D:\Lotus\LotusWin\icon/icons/png/48.png
Created D:\Lotus\LotusWin\icon/icons/png/64.png
Created D:\Lotus\LotusWin\icon/icons/png/128.png
Created D:\Lotus\LotusWin\icon/icons/png/256.png
Created D:\Lotus\LotusWin\icon/icons/png/512.png
Created D:\Lotus\LotusWin\icon/icons/png/1024.png
Icon generetor from PNG:
src: D:\Lotus\LotusWin\icon\icons\png
dir: D:\Lotus\LotusWin\icon\icons\mac
(node:2320) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): Error: TypeError: Cannot read property '[object Array]' of undefined

seems to be the same issue as #3

problem was not sloved

damn that sucks.. :(

I ended up using https://www.npmjs.com/package/png2icons - works as expected


[KYUUBI #3376] Support json_description for PlanOnlyStatement

Why are the changes needed?

Fix https://github.com/apache/incubator-kyuubi/issues/3376
This pr aims to support Json description for PlanOnlyStatement in Spark engine, Users can perform SQL scheduling based on the JSON description of TreeNode.
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

how about add kyuubi.operation.plan.only.output.style=plain,json,etc

Codecov Report

Merging #3377 (d7dc387) into master (1989e4c) will decrease coverage by 0.07%.
The diff coverage is 42.85%.

@@             Coverage Diff              @@
##             master    #3377      +/-   ##
============================================
- Coverage     51.51%   51.43%   -0.08%
  Complexity       13       13
============================================
  Files           479      479
  Lines         26574    26579       +5
  Branches       3711     3713       +2
============================================
- Hits          13689    13671      -18
- Misses        11554    11567      +13
- Partials       1331     1341      +10

Impacted Files
Coverage Δ

...ubi/engine/spark/operation/PlanOnlyStatement.scala
49.12% <0.00%> (-2.73%)
:arrow_down:

...in/scala/org/apache/kyuubi/config/KyuubiConf.scala
96.90% <75.00%> (-0.08%)
:arrow_down:

.../kyuubi/server/mysql/constant/MySQLErrorCode.scala
13.84% <0.00%> (-6.16%)
:arrow_down:

...ache/kyuubi/server/mysql/MySQLCommandHandler.scala
76.13% <0.00%> (-3.41%)
:arrow_down:

...apache/kyuubi/engine/JpsApplicationOperation.scala
77.41% <0.00%> (-3.23%)
:arrow_down:

...ache/kyuubi/server/mysql/MySQLGenericPackets.scala
76.59% <0.00%> (-2.13%)
:arrow_down:

...rg/apache/kyuubi/ctl/cmd/log/LogBatchCommand.scala
78.00% <0.00%> (-2.00%)
:arrow_down:

...che/kyuubi/server/KyuubiTHttpFrontendService.scala
64.23% <0.00%> (-1.46%)
:arrow_down:

...mon/src/main/scala/org/apache/kyuubi/Logging.scala
52.63% <0.00%> (-1.32%)
:arrow_down:

...ain/scala/org/apache/kyuubi/engine/EngineRef.scala
72.26% <0.00%> (-0.85%)
:arrow_down:

... and 4 more

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

what if users want an analyzed json plan?

thanks, merged to master


ElePHPone: README link fixes

In PR #3 I overlooked the changes made to the prepared links made at the bottom of the document. I reverted those changes so the links in the document were working again.
For more information about these prepared links, see the section on "link label" in the official Markdown documentation.

Got it, thanks for the best practice
"The point is that with reference-style links, your document source is vastly more readable."
:+1:


GridFilterFieldSpec.inputProps typed too generically as HoistInputProps

We store and will then spread on any inputProps provided to the type-specific input component that ends up being rendered within the grid filter header's "custom" tab:
https://github.com/xh/hoist-react/blob/c7283cbba9ac52ca86c2cd64a0e228f72d15128a/desktop/cmp/grid/impl/filter/custom/CustomRow.ts#L79
This means we support all props for e.g. dateInput or numberInput, but the typing displays as an error.  We should likely amend to a union type of the PropTypes for all supported inputs - I expect that's the best we can do.

Would be nice to take this typescript off the board, if simple @ghsolomon -- thanks

One complication here - we have different input props for our desktop vs. mobile components, but GridFilterFieldSpec is shared between both.  We could makeinputProps an exclusive union of both mobile and desktop prop types, but then I believe we would also need to break those type definitions out into their own modules so we aren't importing anything but the types into the shared module.

We ultimately decided against changing the GridFilterFieldSpec.inputProps type in order to avoid importing platform-specific code into this cross-platform module.  Applications wishing to ensure type-safety and avoid TS errors can define their input props separately and pass them as illustrated below:
private createGridModel() {
        const inputProps: DateInputProps = {
            maxDate: LocalDate.today()
        }

        return new GridModel({
            filterModel: {
                fieldSpecs: [
                    {
                        field: 'trade_date',
                        fieldType: 'localDate',
                        inputProps
                    }
                ]
            },
            ...
        })
}


FIx dragging user groups

FIx https://github.com/concrete5/concrete5/issues/4845

What's missing is reverting the move if the dragging failed.

What's missing is reverting the move if the dragging failed.

Done in https://github.com/concrete5/concrete5/pull/5370/commits/504c2aee13d01e883b035f26497f8ddf198784ce


delete bloated registry items

delete bloated registry items.
check and delete the registry when launching easytier-gui.
just making modifications to easytier-gui instead of easytier-core

Would you consider integrating this into the easytier-core? The core module also encounters the same issue.

the check & delete code will run before "create_tun".
but I think there must be a better location for this part of code. I tried the "close" and "drop" functions from ring.rs, but the results were always unsatisfactory. I will continue to find the best position. At the same time, due to my skill issues, the code may need to be optimized to better integrate in to the entire program.


Add July course page iteration

We are now planning a new round of testing on the course pages, and include the up front questions in the scope.
We needed to clean up the prototype to ensure that it is understood by others in the future, and so that we have an easy way to retain the previous last to design iterations separate from what we now what to explore.
Previously, the files for the previous and current iteration were combined with the 'Course' and 'Sections' folders

Before

We have now separated out these two versions, and added a new folder for the future iteration to be made in July.

After

May 2024
Child links aren't working:

about provider
about accredited provider
school placements
training with disabilities

Example

July 2024
Link to results isn't working:

Visa sponsorship question
Results page


Format - Day and Month are switched

Hello,
I've encountered a problem when a DateTime input field is filled from the view model (ASP.NET Core).
<input<EMAIL_ADDRESS>type="text" />
MyDate is DateTimeOffset.UtcNow;
The settings for the DateTimePicker are default.
function setDatePicker(selector) {
    selector.datetimepicker({ });
}

Result: 04/06/2017 12:25 PM (OK)
When I add a format (DD.MM.YYYY)
function setDatePicker(selector) {
    selector.datetimepicker({
        format: 'DD.MM.YYYY'
})

The result is 04.06.2017 and not 06.04.2017 which would be correct.
Am I missing something?
I've found simmilar issue https://github.com/Eonasdan/bootstrap-datetimepicker/issues/61
Kind Regards,
Martin

Hi,
I'm not totally sure what are you actually trying
DateTimeOffset.UtcNow show as with a format of  04/06/2017 12:25 PM what is DD/MM/YYYY HH:mm a
and then you format it again as format: 'DD.MM.YYYY' which actually is 04.06.2017
if you want it like 06.04.2017 what is  MM/DD/YYYY
then the format should be
format: 'MM.DD.YYYY' and not format: 'DD.MM.YYYY'
Good Luck!

Hi, I'll be closing this as there's no feedback from original poster, feel free to re open it if need it.


exposed doxygen options EXCLUDE_PATTERNS and FILE_PATTERNS to the ins…

…pector
My project has a large number of Objective-C headers with the .h extension, but I only need to bind things in .hpp headers which have C++ code, so I've exposed the FILE_PATTERNS option.
Moreover, I use boost and I needed to exclude its headers from the bindings, so I've also exposed the EXCLUDE_PATTERNS option.
My editor is configured to remove white space at the end of lines, so I'm sorry for the Doxyfile diff. Let me know if it's a problem for you.

Hi there !
Thanks for these changes :-)
Let's see if I can fix the tests triggered by adding ".H" to Doxyfile first (tests are currently failing on master) and then pull in your changes.

No problem. I'll make another PR to add support for some STL classes I need. My idea is to check for types std::vector< ... > and add them as if they were user-defined classes, including all the public methods.
Is this a good approach, or should I look somewhere else?

I haven't had my head deep in dub for some time, but I think the fastest route would be to create a "VectorSomething" pseudo-header with the methods you need and then simply add a typedef in your real header (the one that will compile with the bindings).

I'm not sure how to implement what you said, but I have many projects and tenths of headers per project, so I need to generate the binds automatically, i.e. without having to create/configure things per class as needed.
Thanks for the suggestion though.


[FLINK-35149][cdc-composer] Fix DataSinkTranslator#sinkTo ignoring pre-write topology if not TwoPhaseCommittingSink

Current , when sink is not instanceof TwoPhaseCommittingSink, use input.transform rather than stream. It means that pre-write topology will be ignored.
private void sinkTo(
        DataStream<Event> input,
        Sink<Event> sink,
        String sinkName,
        OperatorID schemaOperatorID) {
    DataStream<Event> stream = input;
    // Pre write topology
    if (sink instanceof WithPreWriteTopology) {
        stream = ((WithPreWriteTopology<Event>) sink).addPreWriteTopology(stream);
    }

    if (sink instanceof TwoPhaseCommittingSink) {
        addCommittingTopology(sink, stream, sinkName, schemaOperatorID);
    } else {
        input.transform(
                SINK_WRITER_PREFIX + sinkName,
                CommittableMessageTypeInfo.noOutput(),
                new DataSinkWriterOperatorFactory<>(sink, schemaOperatorID));
    }
}

（ps: the modify of StarRocksUtils just apply spotless)

@PatrickRen , CC

Good catch @loserwang1024!
Could you please add a test case to prevent later code changes to revert this fix?

Could you please add a test case to prevent later code changes to revert this fix?

I'd like to, but it seems no pipeline sink which is WithPreWriteTopology but not TwoPhaseCommittingSink now unless i mock one.

Could you please add a test case to prevent later code changes to revert this fix?

I'd like to, but it seems no pipeline sink which is WithPreWriteTopology but not TwoPhaseCommittingSink now unless i mock one.

Could you define your own one in the test itself?
Then you have free hands what it does, and does not...

Could you define your own one in the test itself? Then you have free hands what it does, and does not...

Done it.

@PatrickRen , CC, Would you like to help me review this PR?

Hi @loserwang1024, could you please backport this patch to release-3.1 branch so that it could be released with CDC 3.1.1?

Hi @loserwang1024, could you please backport this patch to release-3.1 branch so that it could be released with CDC 3.1.1?

I'd like to, but it haven't been merged to master.

@loserwang1024 Could you cherry-pick this commit to release-3.1 branch? Thanks


Text upon fast withdrawal disappears below 'switch layer' button

when metamask is set to L1 and user clicks on fast withdrawal, the text to set metamask to L2 disappears half way under 'switch layer' button. consider shorting to 'switch to L2'

Same goes for when L2 is active and user is prompted to switch to L1

Done!

Changes done and merge into the develop branch.


KOGITO-7623: Specs folder is not detected in Windows on SWF VSCode Extension

Fixes https://issues.redhat.com/browse/KOGITO-7623
Fixes https://github.com/kiegroup/kie-tools/issues/1113

Parse all files and directories paths as POSIX;
Fix FsWatcher for specs files;
Saves kogito.yard.automaticallyOpenDiagramEditorAlongsideTextEditor and kogito.swf.automaticallyOpenDiagramEditorAlongsideTextEditor settings to the user's settings.json file;
Only show prompt for automatic opening diagram view for SWF or Yard files;

@thiagoelg @tiagobento Probably yard-editor is affected by the same issue... Can you please check and case fix it? The code should be the same?

@thiagoelg thanks for the quick fix!


Document memoization as alternative to componentWillReceiveProps

We get a lot of feedback that getDerivedStateFromProps is used for memoization which is not very ergonomic.
Let’s add a recipe about memoizing directly to the docs.
https://twitter.com/brian_d_vaughn/status/987443099537309696?s=20
We should probably use this package:
https://www.npmjs.com/package/memoize-one
It’s important to highlight that we usually recommend memoizing just the last value.

@gaearon Can I take this?


Builder support for x64 architecture

I've noticed that the builder can only output x32-bit architecture binaries. For compatibility with x64-only software, I wonder if it would be possible to implement the possibility between choosing which architecture to output.

yes, it is possible to build client and server as 64bit :)


[D2Game] Error D2GAME_MERCS_EquipItem_6FC88D10

When we use the sword in mercenaries act 3, the item will disappear because the function only checks the item on the right hand side, not on the left hand side, and so are the other entries it seems to work only in the right hand.
Origin:
uint8_t nTargetBodyLoc = nBodyLoc1;
if (pMerc->dwClassId == MONSTER_ACT3HIRE && ITEMS_CheckItemTypeId(pItem, ITEMTYPE_SHIELD))
{
        pExchangeItem = pTempItem;
        nTargetBodyLoc = nBodyLoc2;
}

Fix:
uint8_t nTargetBodyLoc = nBodyLoc1;
if (pMerc->dwClassId == MONSTER_ACT3HIRE && ITEMS_CheckItemTypeId(pItem, ITEMTYPE_SHIELD))
{
        pExchangeItem = pTempItem;
        nTargetBodyLoc = nBodyLoc2;
}
else
{
        nBodyLoc2 = nTargetBodyLoc;
}

Unless I am missing something, this can not be the full fix because nBodyLoc2 is not unused anymore after this block

sorry i was wrong, thanks for the reply, you can delete or close this topic


Add Note About PDF Structure on Quickstart: Build a Retrieval Augmented Generation (RAG) based LLM assistant using Streamlit and Snowflake Cortex

Describe the improvement
In step two of this RAG Quickstart, it should be made clear that the PDFs have to be in text format. I think we need to add the following text at the bottom of step one:
NOTE: This Quickstart uses the PyPDF library to extract text from the documents above. If you swap out these documents with others, make sure they are text based PDFs. If you have scanned PDFs (e.g. images), you will need to add a step to convert the image to text using a library like tesserocr.
URL of where you see the bug
https://quickstarts.snowflake.com/guide/asking_questions_to_your_own_documents_with_snowflake_cortex/index.html?index=..%2F..index#1
To Reproduce
If you try to process a scanned PDF with no text, the output of the pdf_text_chunker process will be NULL (as expected).
Expected behavior
Longer term, we could modify the pdf_text_chunker function to add functionality to extract text from images as well.
If  extract text and chunk it, else
If , OCR to text then chunk it, else
Return "No text found"
Screenshots
N/A
Desktop (please complete the following information):
N/A
Smartphone (please complete the following information):
N/A
Additional context
Add any other context about the problem here.

+1

+1

Added this note:
NOTE: This Quickstart uses the PyPDF library to extract text from the documents above. If you swap out these documents with others, make sure they are text based PDFs. For example, if you have scanned PDFs (e.g. images), you will need to add a step to convert the image to text using a library like tesserocr. Similarly, if you have password protected PDFs, you will need to use a different Python library.


can't load tests to runner

Are you requesting a feature or reporting a bug?
bug
What is the current behavior?
Error: Cannot find a test source file at
What is the expected behavior?
I can't use glob or *.spec.js I have to write particular test name
How would you reproduce the current behavior (if this is a bug)?
Provide the test code and the tested page URL (if applicable)
Tested page URL:
Test code
const createTestCafe = require('testcafe')
let testcafe = null

createTestCafe('localhost', 1337, 1338)
  .then(tc => {
    testcafe = tc
    const runner = testcafe.createRunner()
    return runner
      .src(['tests/e2e/specs/test1.spec.js']) // I'd like to use tests/e2e/specs/*.spec.js
      .browsers(['chrome'])
      .run()
  })
  .then(failedCount => {
    console.log('Tests failed: ' + failedCount)
    testcafe.close()
  })

Specify your

operating system: windows 8.1
testcafe version: "testcafe": "^0.16.2",
node.js version: v6.9.3

Duplicate of https://github.com/DevExpress/testcafe/issues/980


[Question] Difference between parameters in config.yaml

:question: Question

Hi,
May I ask whats the difference between parameter in config.yaml under augmentation:transforms:NoAug and augmentation:transforms:BaseMoreAug and what part of the code are related with this parameter?

Thanks!

Hi,
the transforms parameter defines the transformations which should be used for augmentation during training. Their implementation can be found here: https://github.com/MIC-DKFZ/nnDetection/blob/main/nndet/io/augmentation/bg_aug.py


Rewrite Osram Lightify component

Description:
Pull request in home-assistant.io with documentation: home-assistant/home-assistant.io#8621
Original code had multiple flaws: it was not performance efficient, used throttling incorrectly, implemented status of light groups in a confusing way, didn't take into account actual supported features of each device and lacked many functional features.  As a result, the module was re-implemented literally from scratch.  At the same time I did my best to keep the new code 100% compatible with the old version not to break existing installations (see also Known limitations below).
Summary of changes:

Upgrade underlying python-lightify library from <IP_ADDRESS> to <IP_ADDRESS>.  It was recently updated by me as well.  The changes include:

Dramatically improve performance by avoiding redundant queries and applying additional optimizations during parsing results
Add support for scenes
Set properties that don't exist for a particular device type to reasonable defaults
Expose supported features and ignore unsupported actions
Expose additional properties like firmware version and whether the lights are reachable or not
Add new device types and improve handling of unknown device types
Add built-in throttling mechanism
Additional refactoring

Further improve performance on Home Assistant level:

Use different frequency for updates of light statuses (need to be near real-time) and group configurations (for most users may be updated once per hour or even less frequently)
Fix throttling.  Existing throttling was simply broken: update function was always called with no_throttle=True.  Now built-in throttling of the underlying library is used.  It's more lightweight and also correctly handles errors: if some call failed, it doesn't throttle the next one.
Cache calculated values when possible to avoid unneeded recalculations

Add additional configuration values to allow users to control throttling and which types of devices (like swithes or sensors) should be loaded or not.

Add support for scenes.  If a group has associated scenes, they will be imported as light effects and visible in Effect dropdown on UI.  Also they may be applied using light.turn_on service.

Expose device availability and new properties provided by the underlying library.

Take into account supported features of each device (don't treat all devices as RGBW bulbs).

Correctly report statuses of light groups.

Other minor fixes and improvements.

Known limitations:

The module is still not able to distinguish "color" and "tunable white" modes of RGBW bulbs and to get battery levels of switches (that seems not possible using the local protocol).

Support for motion and contact sensors is not implemented.  It's definitely possible, but I don't own any of them to do an accurate fix and test it properly.  See also https://github.com/tfriedel/python-lightify/issues/9.  As a workaround, the module exposes a list of all raw sensor values and users may still use them for automations.  Please note that currently osramlightify is a pure light module, but making motion and contact sensors first-class citizens will require rewriting it to a custom component like hue or xiaomi_aqara.

The module does its best to support unknown devices (many 3rd party manufacturers start to produce Lightify-compatible bulbs), but minor issues like incorrect temperature ranges are still possible.  The module exposes original device type id, so now it should be easier to report bugs for specific devices.

unique_id for Lightify groups is calculated in a wrong way, but I have decided not to fix that not to break existing installations.  When the module is re-written to a custom component (see p. 2 above), it should be a right time to fix unique_id issue as well.

Example entry for configuration.yaml:
light:
  - platform: osramlightify
    scan_interval: 1
    host: <IP_ADDRESS>

Checklist:

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

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

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

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

[x] New dependencies have been added to the REQUIREMENTS variable (example).
[x] New dependencies are only imported inside functions that use them (example).
[x] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

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

This is an unnecessary large PR, combining new features and refactoring at the same time. You should split this up to smaller portions.

@Kane610 Your concern is valid, but please note the module was re-implemented from scratch (I used a word "refactoring" incorrectly).  I have updated my description above:
"Original code had multiple flaws: it was not performance efficient, used throttling incorrectly, implemented status of light groups in a confusing way, didn't take into account actual supported features of each device and lacked many functional features. As a result, the module was re-implemented literally from scratch. At the same time I did my best to keep the new code 100% compatible with the old version not to break existing installations (see also Known limitations below)."
Does it make sense?  Honestly I don't see an easy way to logically split it and I doubt that could help to compare the differences (because all the code is new, except for the general structure, inherited from the parent class).  I could artificially extract some biggest features like scenes just to minimize a total number of lines, but I'm not sure it's a good idea (and would require a lot of additional testing).
What do you think?
Thanks!

Hello,
i saw you PR and i am very exited to get the rewritten component.
There is still something in it that disturbs me:
The unique_id of the group is a collection of the group members. So everytime the group members change a new light is created in HA.
A Fixture might be to use the group name and something like SHA1 (in this case security doesn't matter) to create a hash:
Livingroom ->4db1d0d44ea4a7e4036f08b60c1f49c4cc8bd0cf
Now add a prefix like you componentname and the result should be unique enough.
osramlightfy_4db1d0d44ea4a7e4036f08b60c1f49c4cc8bd0cf
I don't know the python implementation, but normally the hash should always be the same.
BR
Markus

@SukramJ Your concern is 100% valid, but as I mentioned in the description:
"4. unique_id for Lightify groups is calculated in a wrong way, but I have decided not to fix that not to break existing installations.  When the module is re-written to a custom component (see p. 2 above), it should be a right time to fix unique_id issue as well."
I could fix that, but that would trigger new lights instead of old groups in each of existing HA installations.  I'm not 100% sure it is worth it.  I hope sooner or later this component will be extended to include not only lights, but also sensors (like xiaomi_aqara).  It's a backward incompatible change by itself, so probably it makes sense to apply all breaking changes at the same time.
Thanks!

I installed it as custom_component and it works really good.
Especially that light or plugs show only features they support is fine.
Please remove the debug output from the library.
BR
Markus

@SukramJ Are you referencing this line?
bridge = lightify.Lightify(host, log_level=logging.DEBUG)

It should not set the actual logging level, that code should just allow you to set DEBUG level when you need it like:
logger:
  default: info
  logs:
    lightify: debug

Without passing log_level=logging.DEBUG you are not able to set anything below INFO for the lightify module.
Do I miss anything?
Thanks!

I haven't set any debug level in my config.
But my Output is full of debug stuff.
2019-02-21 17:54:43 DEBUG (SyncWorker_9) [lightify] Received "2 b'2903'"
2019-02-21 17:54:43 DEBUG (SyncWorker_9) [lightify] Length:   809
2019-02-21 17:54:43 DEBUG (SyncWorker_9) [lightify] Expected: 809

Hundrets of these lines.
After setting this:
logger:
  default: info

... the debug stuff is gone.

@SukramJ According to https://www.home-assistant.io/components/logger/:
default
    (log_level) (Optional) Default log level.
    Default value: debug

So, probably it's expected that you see all debug messages.  Did you see them only for this module or for the whole HA?
Thanks!

I see them only for lightify.
BTW: This is a new installation with pip.

@SukramJ Ok, I will double check.  Thanks for the feedback!

@SukramJ I can't reproduce your issue with logging:

If logger is completely commented in configuration.yaml, I see only WARNING+ messages for all components.

If I have just:
logger:

I see DEBUG+ messages for all components (according to documentation).

If I have:
logger:
  logs:
    lightify: info

I see DEBUG+ messages for all components, but only INFO+ for lightify (according to documentation).

If I have:
logger:
  default: info

I see INFO+ messages for all components, including lightify (according to documentation).

If I have:
logger:
  default: info
  logs:
    lightify: debug

I see INFO+ messages for all components, and DEBUG+ for lightify (again, according to documentation).

Do I miss anything?  I'm using the latest 0.88.1 version.
Thanks!

This is my latest test setup:

Debian 9 netinst
install pip3
install homeassistant python3 -m pip install homeassistant
default configuration.yml with added lightfy:

homeassistant:
  # Name of the location where Home Assistant is running
  name: Home
  # Location required to calculate the time the sun rises and sets
  latitude: 53.5389
  longitude: 10.128
  # Impacts weather/sunrise data (altitude above sea level in meters)
  elevation: 0
  # metric for Metric, imperial for Imperial
  unit_system: metric
  # Pick yours from here: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
  time_zone: Europe/Berlin
  # Customization file
  customize: !include customize.yaml

# Configure a default setup of Home Assistant (frontend, api, etc)
default_config:

# Show the introduction message on startup.
introduction:

# Uncomment this if you are using SSL/TLS, running in Docker container, etc.
# http:
#   base_url: example.duckdns.org:8123

# Sensors
sensor:
  # Weather prediction
  - platform: yr

# Text to speech
tts:
  - platform: google

group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml

light:
  - platform: osramlightify
    host: xx.xx.xx.xx
    allow_lightify_nodes: true
    allow_lightify_groups: true

start hass
osram lightfy works without debug logging
mkdir -p custom_components/light
copy osramlightify.py to new directory
restart hass
now debug logging is in console

I did not update the library in this latest test, but in previous test i did.
Everything works fine in HA with new component.
Have you tested osramlightify.py as custom_component?
Is the debug code related to custom_component?
Thats all i can say.
Thanks.

@SukramJ Well, I never tried installing osramlightify as a custom component.  Also I don't think anybody will need to do that after the changes are merged.
Possibly logging configuration works differently for custom components.
Thanks!

@SukramJ Could you please test again?  Now logging should work correctly in all cases (thanks @tfriedel for the fix).

Logging is OK now.

@OleksandrBerchenko there seems to be a lot in this PR as mentioned earlier.  I don't think there is anything wrong with a rewrite to fix things however you are also adding features at the same time.  If you can split up this PR by removing all new features and just rewriting the current code it will probably get merged in faster.  Then your subsequent PR's for adding each new feature will get merged faster.  I don't have merge rights but I am speaking from experience here.

@dshokouhi Thanks for the suggestions.  Ok, I will try to manage that separation.  Anyway, I already got a conflict that I need to fix.

Ok, I have closed this one and opened the first of the new series: https://github.com/home-assistant/home-assistant/pull/22184.


Monocular skips charts without a README

Why does monocular skip charts without a README? According to https://docs.helm.sh/developing_charts/, a README is optional.

We currently skip charts without READMEs because nothing would be shown in the chart page, but we could make this optional and have a default README show on that page instead. Even though I think it is more useful to show the README, given that a lot of charts don't have one it would make sense to fix this for compatibility.
In the meantime, you could add a blank/one-line README to your charts.

Sounds good. Thanks! Feel free to close this or keep it open to track this issue.


Speed up consignment validation

intro
consignment validation is currently very slow, as can be seen by running rgb-lib's stress test
as detailed in #122, part of the slowness can be attributed to the code re-validating the same nodes multiple times, which will be fixed in that issue
issue
even with #122 fixed, validation can still be very slow for consignments with a long history, as all transitions (nodes) need to be validated again each time rgb-core's Validator::validate is called
once a transition has been validated, it might need re-validating in cases where any concealed or revealed values have changed. not all schemas should have this property, though. as an example, RGB20 transitions should be completely immutable so re-validation should be avoidable. doing so would yield a great speed-up when validating consignments with a long history
in theory, re-validation could be avoided (where possible) by e.g. having rgb-core's Validator::validate  function take an optional list of nodes that don't need to be validated again. this way the list of known-good nodes is handled by caller
having the Validator::validate caller store the list of nodes that have already been validated to persistent storage (e.g. to an on-disk DB) should then massively shorten validation times after an RGB node restart, while avoiding additional dependencies on rgb-core's side
I suggest we start by avoiding re-validation where possible and then optimize other areas where speed can be improved (e.g. electrum calls)
electrum
slowness in validation is supposed to be mostly due to electrum calls taking a long time to complete, so replacing electrum with bp-node (currently being developed) as the indexer has been proposed to speed things up
from the stress test logs it's not clear if calls to the electrum server are the main bottleneck
considering that the stress test starts from a clean regtest blockchain and that all services are local, electrum queries are expected to be blazing fast. moreover, electrum query times should remaining pretty consistent as the test progresses, as there are just roughly a hundred blocks to be indexed and the number grows by only one each transfer

Consignment example
consignment_out.txt

Solved by removing bulletproofs - 99% of time in RGB core was spent on bulletproof validation as a inside of grin_secp256k1zkp. In v0.10, since we temporarily not using bulletproofs, the issue is solved. There is still seconds spent somewhere in the RGB Tools code, but this is different issue, external to RGB Core.
In the future we will have to do a significant benchmarking of bulletproofs implementation before starting using it.


Purge remote translog asynchronously from a dedicated threadpool to avoid penalties on indexing or flush latencies for remote-backed indexes

Is your feature request related to a problem? Please describe.
As part of of #5845, the translogs are purged considering the latest metadata. This makes sure that relocation/failover after a flush does not remove all translogs which leads to failure in cluster bootstrap. We have this as async, but there is no dedicated threadpool.
Describe the solution you'd like
Create a dedicated threadpool for purging of remote translog files.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Completed with https://github.com/opensearch-project/OpenSearch/pull/6109


Configuration file validation not working

It looks like the configuration file validation (https://github.com/E3SM-Project/zppy/blob/main/zppy/main.py#L169) isn't working anymore.
While working on #281, I tried removing a trailing comma and the validator passed, even though it has historically failed in such cases -- see #290. I tried setting active = 4, which I would have expected to fail since active expects a bool value; however validation passed and a ValueError: Invalid value 4 for 'active' appeared during runtime.
It appears that something has changed in the validation process.

I tried going back to v2.0.0 (Feb. 2022 -- https://github.com/E3SM-Project/zppy/releases/tag/v2.0.0):
$ git checkout -b test-validation<PHONE_NUMBER>3cc3ad9351e4a98902bd20fce5c163
$ emacs tests/integration/test_complete_run.cfg
# Set `active = 4`, remove a trailing comma for `years`
$ pip install .
$ zppy -c tests/integration/test_complete_run.cfg
# Behavior is the same as above.

This occurs regardless of using a conda environment from July 2022 or from building a conda environment based on the setup of the code in Feb. 2022.

#338 will at least fix the trailing comma error, so this is not urgent for the December 2022 release.


Expose an API to launch a url in browser

VSCode uses shell.openExternal from electron to launch urls in the browser. There are some places I'd like to do the same but it seems doing it manually requires platform-specific code (or another third party package to hide that).
Is it possible vscode could provide a wrapper for eletron's shell.openExternal? Taking a dependency on Electron directly seems crazy (if it'd even work) because we'd have to manually keep the version in sync with VSCode (not to mention it's a lot of API to pull in for one method).

At the moment we can use a node module like node-open, but it would be nice to have it by default in the vscode api as well.

I saw that one .. and that it had 19 open issues on GH (some of which seem pretty basic)! That's what got me curious about what Code did and I looked in the code to find Electron already had it :)

(maybe) If you only need a browser, try https://github.com/sindresorhus/opn

I'm trying to avoid external dependencies if I can help it; vscode extensions run on end users machines with access to a lot of stuff; I think it's irresponsible to pull in third party code from relatively-unknown devs without reviewing it. That package has two of its own dependencies and one of those has another! This is all literally so I can have a button to link the user to a download page! I'd rather just write the little xplat code myself; but since Electron already has it I thought I should ask before I re-implemented it :-)

wouldnt this do it?
vscode.commands.executeCommand('vscode.open', vscode.Uri.parse('http://www.google.com'));

wouldnt this do it?
vscode.commands.executeCommand('vscode.open', vscode.Uri.parse('http://www.google.com'));

Oooooh, quick test and this seems to work!
However, the docs say (emphasis mine):

vscode.open - Opens the provided resource in the editor. Can be a text or binary file, or a http(s) url

If it opened inside the editor, that wouldn't be what I want. I'm not why it does what I want and not what it says, but maybe someone can confirm and/or update the docs with the real logic?

from my testing, if its an external webpage it will open it in the default browser.
if its a file it will open it in the editor.
i would love to find a way to open an external webpage inside the editor itself :)

The recommendation is to use a node module or the aforementioned command


Italian communications + EN url regex improvement

Adding IT communications (phone number, url, email) and improving url regex for English

Thank you


Could not pass event Issue

Server version: Spigot 1.13.2
OldCombatMechanics version: 1.6.6
Server log file: https://pastebin.com/0krhJfVW
OldCombatMechanics config file: Default

Problem Description

So whenever I tried to do an event, for example, equipping armor,  join, and leave. It gives me an "Could not pass event" problem. This is my first time loading OCM, so I have not changed the config.

List of Plugins: EssentialsX, Holographic Displays, KeepChunks, Multiverse Core, NTE, OCM, PEX, Plugman, ProtocolLib, Titlemanager, Vault, Worldedit, Worldguard.

I have not configured my plugin either. I have a similar problem, here is my pastebin. https://pastebin.com/EmCfTYme
I get errors when I connect and disconnect with armor and also sometimes during combat.
[22:24:41 INFO]: Plugins (30): AddLight*, Banknotes*, DiscordSRV, EasyBackup*, Essentials, EssentialsSpawn*, Factions, HolographicDisplays, KeepChunks, LuckPerms*,
mcMMO, ObsidianDestroyer*, OldCombatMechanics*, Orebfuscator4, PlaceholderAPI, PlayerHeads*, PlayerVaults, PlayerVaultsGUI, ProtocolLib*, SilkSpawners, TabList*,
Trading*, Vault*, Votifier, VotingPlugin, Wild, WorldBorder, WorldEdit, WorldGuard, WorldGuardExtraFlags*

Duplicate of #249 #246 #245 #253 #266 #269 #297 #299. Please use the latest test build of OldCombatMechanics from here.


Update README to show how to run this task automatically

tasks.whenTaskAdded {
  if (name == "assembleDebug") {
    dependsOn("licenseDebugReport")
  }
}

tasks.whenTaskAdded {
  if (name == "assembleRelease") {
    dependsOn("licenseReleaseReport")
  }
}

In order to accommodate Product variants in Android, something like this should also work:
tasks.whenTaskAdded {
    if (name.contains("assemble") && name.contains("Release")) {
        dependsOn("licenseReleaseReport")
    }
}

tasks.whenTaskAdded {
    if (name.contains("assemble") && name.contains("Debug")) {
        dependsOn("licenseDebugReport")
    }
}

This because the tasks are named: assembleProductVariantNameRelease.
Although your example would work too, in a very specific case where the exact task is run for generating all variants. The one suggested in this comment, could avoid extra processing of all variants to get the output.

I might add automatic support for this, similar to https://github.com/jaredsburrows/gradle-spoon-plugin/blob/master/gradle-spoon-plugin/src/main/kotlin/com/jaredsburrows/spoon/projectAndroid.kt#L63.

That looks much better. TIL 😸
Looking forward that being implemented.


(maint) Update Puppet VS Code Extension ID

This commit updates the configuration file to point to the official Puppet VS Code Extension puppet.puppet-vscode

This change only affects users who open this repository inside VS Code and will not affect any module code. This is safe to merge. It is required to move users to the official Puppet VS Code extension

hey, could someone from @puppetlabs/dio please take a look at this? Thanks!

I do not have permissions to self merge, so someone on the team will have to merge this

We are involved b/c I basically wrote the module as part of deploying internally @highb :)


Less RAM

picks up @szszszsz's https://github.com/solokeys/fido-authenticator/pull/8
substantially reduces stack usage
fixes a few other bugs
cargo clippy + cargo fmt

The cargo fmt is done at the very end, so the significant changes can be tracked commit by commit.

Probably a dumb question, but anyway - may I ask how do I get notified when this change gets its way to the firmware release? Having issues with too long key handle in a few services. Thanks!

You can "Watch for releases" of https://github.com/solokeys/solo2 (top-right, watch, custom, releases) or check the https://github.com/solokeys/solo2/releases page by hand, for now.
I have a firmware that's basically ready except I don't have a working NFC testing setup and I think I may have borked it (as this firmware "doesn't work" on my Pixel 5).

Any news on a release of a new firmware that would render the Solo2 usable on the other half of the internet?


Turning on Cloudwatch export metrics results in a WebMvcMetricsAutoConfiguration error

Hi,
Using Eclipse to create a Spring Boot 2.0.0.RELEASE starter project with MVC + Actuator + Spring Cloud AWS Finchley.M8 + AWS Actuator and turning on Spring Cloudwatch export metrics via
     spring.metrics.export.cloudwatch.namespace=somenamespace
I get the following error

***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 0 of method webMvcMetricsFilter in org.springframework.boot.actuate.autoconfigure.metrics.web.servlet.WebMvcMetricsAutoConfiguration required a single bean, but 2 were found:
	- simpleMeterRegistry: defined by method 'simpleMeterRegistry' in class path resource [org/springframework/boot/actuate/autoconfigure/metrics/export/simple/SimpleMetricsExportAutoConfiguration.class]
	- cloudWatchMeterRegistry: defined by method 'cloudWatchMeterRegistry' in class path resource [org/springframework/cloud/aws/autoconfigure/metrics/CloudWatchExportAutoConfiguration.class]

which I assume is a bug.  What's worse is there is no workaround as turning off SimpleMetricsExportAutoConfiguration using management.metrics.export.simple.enabled=false
results in another similar issue:

***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 0 of method webMvcMetricsFilter in org.springframework.boot.actuate.autoconfigure.metrics.web.servlet.WebMvcMetricsAutoConfiguration required a single bean, but 2 were found:
	- noOpMeterRegistry: defined by method 'noOpMeterRegistry' in class path resource [org/springframework/boot/actuate/autoconfigure/metrics/NoOpMeterRegistryConfiguration.class]
	- cloudWatchMeterRegistry: defined by method 'cloudWatchMeterRegistry' in class path resource [org/springframework/cloud/aws/autoconfigure/metrics/CloudWatchExportAutoConfiguration.class]

Action:

Thanks

Same with WebFlux. Was working in a prior Finchley milestone (or spring boot ?)

Description:
Parameter 0 of method webfluxMetrics in org.springframework.boot.actuate.autoconfigure.metrics.web.reactive.WebFluxMetricsAutoConfiguration required a single bean, but 2 were found:

simpleMeterRegistry: defined by method 'simpleMeterRegistry' in class path resource [org/springframework/boot/actuate/autoconfigure/metrics/export/simple/SimpleMetricsExportAutoConfiguration.class]
cloudWatchMeterRegistry: defined by method 'cloudWatchMeterRegistry' in class path resource [org/springframework/cloud/aws/autoconfigure/metrics/CloudWatchExportAutoConfiguration.class]

Hi @mathieufortin01 , I temporarily got around this issue by copying CloudWatchExportAutoConfiguration, CloudWatchProperties & CloudWatchPropertiesConfigAdapter to a local JAR and the key is adding @AutoConfigureBefore(SimpleMetricsExportAutoConfiguration.class) to CloudWatchExportAutoConfiguration.
Thanks
P.S. I also changed the metric key "spring.metrics.export.cloudwatch" to something else so I don't clash with the spring cloud aws config key.

Hi.
I'm now migrating to boot 2 and having same issue in spring-cloud-aws-autoconfigure:2.0.0.M4
Should we change key from spring.metrics.export.cloudwatch to management.metrics.export.cloudwatch same as spring-boot 2 properties ?

I compared the CloudWatchExportAutoConfiguration  with one from spring-boot-actuator-autoconfigure for Datadog. Looks like we are missing a AutoConfigureBefore annotation and by the time the bean is created simpleMeterRegistry is already created as a fallback.
As a workaround I copied CloudWatchExportAutoConfiguration and CloudWatchPropertiesConfigAdapter into my project with the added AutoConfigureBefore which fixed this error for me.
PS: to get it finally working I also head to hardcode  batchSize() to return 20 ;-)


Naming

Thanks for the module!
I have some suggestions:
Change the module name to include capital letters? all other webmin modules have the second word as capital.
So
Docker container management
to
Docker Container Management
or I would prefer just:
Docker Containers
it would also be cool to get the icon checks for the status like for server dashboard:

Good suggestions
I've just made the naming change and there's a minor release up. I'll look at doing the icons in the next day or two


[WIP] Chore/update ember-cli to 3.0.0

Thanks for taking on this task. Let us know when you’d like us to have a look 👍

@jgwhite Unfortunately I ran out of time to finish this (underestimated my lack of experience with ember testing, especially the new API). Could you help me figure out how to import / reference the custom test helpers this addon defines (drag and reorder)? See FIXME comment in https://github.com/jgwhite/ember-sortable/pull/177/files#diff-c1ef8f3d7d1851c001639465c61178b6
There were also some things that looked just plain wrong in the tests. For example, the test to check that 'isDragging' / 'isDropping' get set to false (during willDestroyElement hook) actually calls destroy() which prevents willDestroyElement from getting a chance to change them (since the object is already destroyed rather than just scheduled for destruction the calls .set(...) result in an error). I changed that to use clearRender() instead of destroy, so that one should be good, but it makes me wonder if maybe the test suite is just a bit out of date and could use some :heart: regardless of my original goals of this PR (i.e. to update ember-cli and eliminate a deprecation warning).

Could you help me figure out how to import / reference the custom test helpers this addon defines (drag and reorder)?

I think, due to the way the test-support tree is merged into the build, it’ll need to be:
import { drag, reorder } from 'dummy/tests/helpers/ember-sortable';

There were also some things that looked just plain wrong in the tests. For example, the test to check that 'isDragging' / 'isDropping' get set to false (during willDestroyElement hook) actually calls destroy() which prevents willDestroyElement from getting a chance to change them (since the object is already destroyed rather than just scheduled for destruction the calls .set(...) result in an error). I changed it to use clearRender() instead of destroy(), so that one should be good, but it makes me wonder if maybe the test suite is just a bit out of date and could use some ❤ regardless of my original goals of this PR (i.e. to update ember-cli and eliminate a deprecation warning).

Wow, yeah. That test is super, super old and I’m not surprised it broke. Your solution sounds good to me. You’re right the tests could do with some spring cleaning.
Are you attending EmberConf?

Sorry, that should have been:
import { drag, reorder } from 'dummy/tests/helpers/ember-sortable/test-helpers';

Which, now that I look at it, is pretty verbose. Wonder if we can make the path shorter?

Unfortunately, I won't be attending EmberConf (in person) this year, though I do hope to go next year. This is a busy month for me, though I do intend to spend a little time working on this again next week.

@jacobq I was able to resolve the unit tests w/ the new testing system like so: https://github.com/jgwhite/ember-sortable/blob/8d47a522aeed0bb37622ea9125c47dc3f0bfe2c2/tests/unit/components/sortable-item-mixin-test.js
I opened a separate PR for upgrading to 3.4.2. Let me know if you have any thoughts.

@validkeys Hey, thanks for working on this! I've got another ember-cli/deps update chore PR to do later this month so will plan to look at this again too. I suspect that another LTS release of Ember will be coming soon too, so so maybe we'll get two birds with one stone.

This project is now being maintained by the team at @heroku.
To get the project healthy and maintainable again, we’re doing a bit of spring cleaning of older issues and pull requests. This pull request seems like it will be superseded by subsequent PRs so we’re closing it. Thank you for all the hard work you put in, the ideas and solutions will live on in other PRs.
Please feel free to re-open if you’d like to resume work on it.

@jgwhite Oops, I forgot all about this! No problem. I'm glad someone is tidying up, and the updates will probably make this irrelevant / unnecessary anyway.


Proposal: Make BLOCK_INTERVAL configurable

I would like to be able to set the block creation time in the development environment to reduce unnecessary latency.

I think I can change the block creation time for gameability, but it seems odd to make it configurable. I will close this issue.

gotcha. what's the alternative you're thinking of?

@kijun I think would be better to set the block creation time suitable for game play through discussions and then update the protocol version of the block.

We may need to adjust block creation time for better gaming experience, but for testing purposes, I'd like to set it even lower, like one second. Could we just add it for single node deployment?


Are optimizer states reloaded or offloaded during the conversion from actor training to actor rollout?

hi veRL team, thanks for open-sourcing the great framework. I have some questions about conversion from actor training to rollout in verl.  I would greatly appreciate any insights or clarifications you can provide.
Questions:
Optimizer State Offload:
During the conversion from actor training to actor rollout, is there an interface provided to offload/reload the optimizer states?
Thanks!

Hi @G1aZzz , do you mean the offload optimizer in Megatron backend? Offload optimizer is supported in FSDP.


core: rework usage of ReportReconcileResult

ReportReconcileResult should never be given an object that is nil. It is
impossible to force compile-time checking for this because the object's
type is an interface. We can't force this, but we can rework the
function definition to handle more cases where the object may not be
returned fully-complete, and we can rework callers to return structs
(not pointers-to-structs) so it is less likely a caller will pass nil
to the function.
Signed-off-by: Blaine Gardner<EMAIL_ADDRESS>(cherry picked from commit c92c6fbc36fbfd01f9f90aca08e4f392b0061f10)
(cherry picked from commit ae1eab91fc9990a72aa347ce0fa68b317a32a7da)

Description of your changes:
Which issue is resolved by this Pull Request:
Resolves #
Checklist:

[ ] Commit Message Formatting: Commit titles and messages follow guidelines in the developer guide.
[ ] Skip Tests for Docs: Add the flag for skipping the build if this is only a documentation change. See here for the flag.
[ ] Skip Unrelated Tests: Add a flag to run tests for a specific storage provider. See test options.
[ ] Reviewed the developer guide on Submitting a Pull Request
[ ] Documentation has been updated, if necessary.
[ ] Unit tests have been added, if necessary.
[ ] Integration tests have been added, if necessary.
[ ] Pending release notes updated with breaking and/or notable changes, if necessary.
[ ] Upgrade from previous release is tested and upgrade user guide is updated, if necessary.
[ ] Code generation (make codegen) has been run to update object specifications, if necessary.

/approve
/lgtm


[MS29] Automatic migration tools #2

This task is the continuation of #2080 and will provide:

[x] additional supported configuration file formats and tools,

See #2080 for a global description of the task.

looks good, thanks


feat: Define ODRL links to scopes and presentation definitions

Description
Defines the linkages between ODRL re/issuance policies and required verifiable presentations. Note that the text references the trust namespace without defining it. This will be done when the trust namespace is introduced to clean up existing namespace issues identified by #7.
Linked Issue(s)
Closes #6

@borisrizov-zf and @matgnt can you add yourselves as reviewers?

@borisrizov-zf and @matgnt can you add yourselves as reviewers?

I can't :/


libcxxrt: unstable-2024-02-05 -> unstable-2024-04-15

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for libcxxrt is: Implementation of the Code Sourcery C++ ABI
meta.homepage for libcxxrt is: https://github.com/libcxxrt/libcxxrt
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found unstable-2024-04-15 in filename of file in /nix/store/iinf29mjblhnwwcnb562w1mxcknwzz7v-libcxxrt-unstable-2024-04-15

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

libcxxrt

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/iinf29mjblhnwwcnb562w1mxcknwzz7v-libcxxrt-unstable-2024-04-15 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libcxxrt https://github.com/r-ryantm/nixpkgs/archive/7ee6936554afed8b2ee2e88e7cd9b187089c9f0d.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/7ee6936554afed8b2ee2e88e7cd9b187089c9f0d#libcxxrt

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/iinf29mjblhnwwcnb562w1mxcknwzz7v-libcxxrt-unstable-2024-04-15
ls -la /nix/store/iinf29mjblhnwwcnb562w1mxcknwzz7v-libcxxrt-unstable-2024-04-15/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

libcxxrt

Maintainer pings
cc @alyssais for testing.

@OfBorg build build pkgsCross.x86_64-freebsd.boost


Implement Stage resource

Issue #, if available: https://github.com/aws-controllers-k8s/community/issues/1126
Description of changes:
Implements support for creating Stage resources in API Gateway.
This is based off the cPu1:resource/integration branch and must be reviewed after merging https://github.com/aws-controllers-k8s/apigateway-controller/pull/10.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/ok-to-test

/retest

/retest

/retest


Governance. Vote. Can't vote as a multisig.

Description
Can't vote as a multisig - shows error:
QR code is invalid. Please make sure you are scanning
QR code for currently signing operation

Operation:

Environment
https://github.com/novasamatech/nova-spektr/commit/f0478b0ec6f2c9a4089e196925d183a21f1c4f22

Status verification: ✅


Not able to install on PopOs 20.04

Im trying to install polybar from git source.
Im using Pop OS 20.04
Im skipping alsalib cause even after adding it, I keep getting issue its not found.
Build Log
./build.sh
** Fetching submodules

Submodule path 'lib/i3ipcpp': checked out 'cb008b30fc5f3febfe467884cb0211ee3c16386b'
Submodule path 'lib/xpp': checked out '044e69d05db7f89339bda1ccd1efe0263b01c8f6'
** A build dir already exists (pass -f to replace)

** Setting build options

** Use GCC even if Clang is installed ----------------------------- [y/N]: n
** Include support for "internal/i3" (requires i3) ---------------- [y/N]: y
** Include support for "internal/alsa" (requires alsalib) --------- [y/N]: n
** Include support for "internal/pulseaudio" (requires libpulse) -- [y/N]: y
** Include support for "internal/network" (requires libnl/libiw) -- [y/N]: y
** Include support for "internal/mpd" (requires libmpdclient) ----- [y/N]: y
** Include support for "internal/github" (requires libcurl) ------- [y/N]: y
** Build "polybar-msg" used to send ipc messages ------------------ [y/N]: y
** Parallelize the build using make -j12 --------------------------- [y/N]: y
** Using compiler: clang++/clang

** Executing cmake command

-- Trying to enable ccache
-- Couldn't locate ccache, disabling ccache...
-- No build type specified; using Release
-- Using supported compiler Clang-10.0.0
CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
  Could NOT find Libiw (missing: LIBIW_LIBRARY LIBIW_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
  cmake/modules/FindLibiw.cmake:15 (find_package_handle_standard_args)
  cmake/common/utils.cmake:79 (find_package)
  cmake/03-libs.cmake:16 (querylib)
  CMakeLists.txt:53 (include)

-- Configuring incomplete, errors occurred!
See also "/home/ajinkya/polybar/build/CMakeFiles/CMakeOutput.log".
See also "/home/ajinkya/polybar/build/CMakeFiles/CMakeError.log".
** Failed to generate build... read output to get a hint of what went wrong

Environment:

Distro (with Version): Ubuntu

❯ pkg-config --exists --print-errors "libpulse libpulse-mainloop-glib"
Package libpulse was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpulse.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libpulse' found
Package libpulse-mainloop-glib was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpulse-mainloop-glib.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libpulse-mainloop-glib' found

it was my mistake.
I forgot to install last line:
apt install build-essential git cmake cmake-data pkg-config python3-sphinx libcairo2-dev libxcb1-dev libxcb-util0-dev libxcb-randr0-dev libxcb-composite0-dev python3-xcbgen xcb-proto libxcb-image0-dev libxcb-ewmh-dev libxcb-icccm4-dev
Built successfully.


add more names to names.coffee

For #53

Coverage increased (+0.007%) to 62.034% when pulling 223e5eec29378e72ff5c2905d3f239770f9fe26f on ZufengW:ZufengW-add-names-1 into 1865cf721a98086ea6873db7b62b1dbaa366c90a on codecombat:master.


Prepare for release of v2.1.0

Allow almost any hashing/digest method supported by nodeJS crypto module
Update and improve test modules
Default to default secret if secret parameter is not provided
Add web-safe Base64 encoder/decoder
Some general fixes for syntax and usage

Ready to merge


ocaml-sodium: init at 0.6.0

Motivation for this change
Trivial packaging of the libsodium bindings for OCaml, that I need for a less trivial one.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Notify maintainers
cc @

@GrahamcOfBorg build ocamlPackages.sodium

May you have a look at the build failure on darwin? It’s probably related to hardening, that you may disable on that platform (see: https://nixos.org/nixpkgs/manual/#sec-hardening-in-nixpkgs). Maybe something like:
hardeningDisable = stdenv.lib.optional stdenv.isDarwin "strictoverflow";

Indeed I had an error on macos:
clang-7: error: argument unused during compilation: '-fno-strict-overflow'

And the suggested change fixes it.
 I couldn't see on the PR page any mention of a failed build.

@GrahamcOfBorg build ocamlPackages.sodium

Here is a failing build, triggered by my first comment.


Add local() helper to CollectionProxy

Stories

As a developer, I want to be able to easily retrieve the local objects of a CollectionProxy using different helpers, while also being able to retrieve remote objects using the existing helpers

Objectives

Add CollectionProxy#local helper that returns a collection of local of sortable and queriable objects

target()


An error in the code

Hello, I found an error in the code while trying to train the model using the Visdrone dataset,
in mmdet-dntr/mmdet/models/roi_heads/cascade_roi_head_cas_t2t_new_jit_mask.py  line 411
        ##### visdrone dataset ###         #self.t2t_cls_head = ModuleList([nn.Linear(128, 11) for _ in range(self.num_stages)])
it should be ModuleList([nn.Linear(128*9, 11),or it will cause thr error:  numel: integer multiplication overflow

According to the Visdrone categories, the number here should be 10+1(cls head). Maybe somewhere in the codes should be adjusted.

Fine,I will check it later.Thanks for your reply！


[Bug]: Consider dropping the es-iterator-helpers dependency

Is there an existing issue for this?

[X] I have searched the existing issues and my issue is unique
[X] My issue appears in the command-line and not only in the text editor

Description Overview
Now, I know this is a weird use case and not something promised in your public contract, but hear me out:
Would you please consider reverting commit e1dd37f743649bf43726fe102a16bc71062d8687 and removing your dependency on es-iterator-helpers?
Since commit e1dd37f743649bf43726fe102a16bc71062d8687 has more added lines than deleted lines, I feel its value as a refactoring is fairly neutral at best.
My weird use case:
I'm a curmudgeon who cares too much about node_modules directory size.
It caught my attention that the total size of eslint-plugin-react is as big as eslint itself:
In an empty project:
$ npm install eslint
added 99 packages in 5s
$ du -sh node_modules/
15M     node_modules/
$ npm install eslint-plugin-react
added 93 packages, and audited 193 packages in 3s
$ du -sh node_modules/
31M     node_modules/

I looked into it and discovered that it's because eslint-plugin-react uses many polyfills to support ancient Node.js versions. Not something I need, but I can understand and respect it. 👍
Still, I had too much time and not enough common sense, so I used the npm "overrides" / yarn "resolutions" feature to override those libraries in my project. E.g. I replaced the string.prototype.matchall package with a one line file module.exports = (string, pattern) => string.matchAll(pattern);, and so on. This brought the total node_modules size of eslint-plugin-react down to 2MB - a much more reasonable number.
I am fully aware this is a silly thing to optimize. I'm not running out of hard disk space. It's about the principle. ;)
A world in which my project does not depend on libraries like is-string makes me happier than a world in which it does. ;)
In v7.33.2 this is not so easy to do. The other polyfills were only needed for old Node versions, but Iterator Helpers are still just a Stage 3 proposal and not yet implemented natively in any Node.js version. So it's not as easy for me to hack them out.
Thanks for reading and thanks for your work.
❤
Expected Behavior

eslint-plugin-react version
v7.33.2
eslint version
v8.54.0
node version
v21.2.0

I appreciate your candor and awareness that it’s a silly thing to optimize.
The value of refactors has nothing to do with line count, which is a metric the entire industry learned decades ago was harmful to optimize for.

Oh well. Thanks for replying!

You are correct. is-string was not the best example.
is-string has a much better reason to exist than left-pad, is-even, or is-windows. But it evokes similar feelings in me. I prefer Russ Cox's view on dependencies. I hope that makes sense.
I guess what bothers me is that I don't really see the upside of commit e1dd37f743649bf43726fe102a16bc71062d8687. I don't find it more readable.
But it's up to your taste and your choice. Thanks for your work (even parts I disagree with). ❤