[5.0] Add The Ability To Use Non-Encrypted Cookies

This has been discussed a few times (#6421, #4134, #3440) without resolution. I'd like to offer to write the code for this, but I need to know what direction to take - i.e. would any of these actually make it into Laravel? Here are the options I can think of / find in other issues:
1. The simplest solution, which I have already written code for is to differentiate the encrypted/plain cookies with a prefix before the name when getting/setting them, e.g.:
// Write a cookie named "hello" with a value of "world" (unencrypted)
Cookie::queue('plain::hello', 'world');

// Reading unencrypted cookies
$hello = Cookie::get('plain::hello'); // world

// It won't allow unsigned cookies to be read without the prefix
Cookie::get('hello'); // null

The prefix is TBD - it could be plain, raw, unsigned, unencrypted or something else. Note that the prefix is not actually used in the cookie name that's sent to the browser, because one of the major uses of this is interoperability with non-Laravel applications where we can't choose the cookie name.
I chose :: as the separator here because I think it's very rare for it to be used in cookie names, but technically it's allowed so the Symfony cookie class doesn't complain.
(Potentially there could be other prefixes, e.g. signed:: for the Laravel 3 (or was it 4.0?) method of signing cookies rather than fully encrypting them - if there's any value to that. I'm not sure that there is, just an idea.)
A slight variation would be to use have a suffix like _signed that's actually used in the cookie name for signed/encrypted cookies - and since only Laravel can decrypt them there should be no interoperability issues. But that would break backwards compatibility in a rather insecure & hard to detect way, since existing apps may assume that cookies are encrypted by default, so I don't think it's a good idea.
2. Another option is to have a list of the cookies that shouldn't be encrypted/decrypted in the config:
'unguarded_cookies' => ['legacy_session', 'js-token'],

The advantage is this is the simplest option to understand.
The downside is you can't tell just by looking at the code whether or not a cookie can be trusted. Also packages might need a way to add their own cookies to this list, and I'd suggest adding XSRF-Token to it automatically too.
3. A third option is to have a separate facade for non-encrypted cookies:
PlainCookie::queue('hello', 'world');
$hello = PlainCookie::get('hello'); // world

There is the added complication of Request::cookie() though, which would maybe need an equivalent Request::plainCookie(). My concern with this option is it could require a lot of changes and get a bit ugly - though I haven't actually tried writing any code yet so I may be wrong.
4. For setting the cookies, there could be a wrapper method that creates a different Cookie subclass, telling the middleware not to encrypt them:
Cookie::queue(Cookie::plain('hello', 'world'));

However, I don't think this would work as I can't see any way to ensure that other cookies are still encrypted when reading them (Cookie::get()). The same would apply to adding another parameter to Cookie::make() - though it has a lot already so I wouldn't recommend that one.

If none of these would make it into core, and no-one has a better suggestion, I will probably implement option 1 (or maybe option 2) as a separate middleware package, replacing EncryptCookies.
But I personally think it should be in core because then the XSRF-Token cookie doesn't need to be encrypted unnecessarily, removing ~238 bytes from every request & response (pre-gzip) and saving some confusion.

What about a chained approach, like Cookie::plain()->get('something') and Cookie::plain()->queue('hello', 'world');?
Of your four options, my preference is the third one.

i love most the idea of Cookie::plain()->get('something') and maybe by default leave Cookie functions without plain to be encrypted ...
Just to keep it simple ;)

I like that - it fits with the rest of the framework better.

I've wanted something like this for a long time, so I'm all for it.
I think having a separate cookie queue (basically proposal 3) would be the best way to go.

I'm currently thinking of something like this:
// Plain method returns a driver object, as mentioned above
Cookie::plain()->get('something');

// The default driver would be called 'encrypted':
Cookie::get('something'); // Equivalent to:
Cookie::encrypted()->get('something');

// It would then be possible for users to add additional drivers:
// e.g. Signed but not encrypted, like in Laravel 4.0(?)
Cookie::register('signed', 'SignedCookieDriver');
Cookie::signed()->get('something');

I'm not sure if I got the terminology or method naming correct - just working from memory - but I think this is similar to other parts of Laravel.
I would then move the cookie encryption/decryption out of the middleware and have the 'encrypted' driver do it on the fly, putting cookies into the response already encrypted. (Not sure if that'll cause a problem for unit testing... Might need to add a getPlainValue() method to the cookie class for that - or getResponseValue() for the response to use - or something like that...)
The ability to add cookies that are signed but not encrypted is something I'd also like to see in core Laravel again, as they're smaller for non-sensitive data, but I think the ability to create custom drivers would be useful anyway - e.g. I have to set cookies to pass data to another application which are signed in a particular way. On the other hand I could continue to sign them in the app code as long as there was a way to set plain cookies.
Of course all of that depends on Taylor signing it off - I see little benefit to doing it this way in a package. If I have to go the package route, options 1 or 2 seem to be much easier to implement because of the way the middleware currently works.

:+1:

+1 for this, I have wanted something like this in the past and I love the chained method idea, definitely fits with the rest of the framework.

@taylorotwell Can you tell us which direction you'd prefer? I don't want to put any work into this if I ultimately do something you won't like...

Personally, I really like @davejamesmiller's way. https://github.com/laravel/framework/issues/6679#issuecomment-74554788

@RomainLanz +1 to that too, I love @davejamesmiller's propsal

:+1:

+1 for @davejamesmiller

+1 for @davejamesmiller

For anybody interested in this, I've finally submitted a pull request, implementing a blacklist in the middleware.


battery: energy direction maybe wrong?

Describe the bug
I have a battery attached to my pv installation (AC with inverter) and the Victron Cerbo shows me positive power values when the battery is charged and negative value when energy from the battery is used.
In evcc it seems that positive values are on the generator side (like pv meter) and so the display is wrong.

In the picture the battery is charging (positive values in mqtt).
Steps to reproduce
Start evcc.
Configuration details
- name: grid
  type: custom
  power:
    source: mqtt
    broker: localhost:1883
    topic: cerbo/ACPOWER

site:
- title: xyz
  residualPower: 200
  meters:
          pv:
            - pv
            - mikrowr
          grid: grid
          battery: mybat

Log details
Oct 17 16:01:37 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:37 battery soc: 53%
Oct 17 16:01:37 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:37 battery power: 2855W
Oct 17 16:01:37 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:37 grid power: -3W
Oct 17 16:01:37 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:37 site power: 3052W
Oct 17 16:01:47 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:47 ----
Oct 17 16:01:47 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:47 pv power: 3330W
Oct 17 16:01:47 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:47 battery soc: 53%
Oct 17 16:01:47 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:47 battery power: 2670W
Oct 17 16:01:47 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:47 grid power: -16W
Oct 17 16:01:47 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:47 site power: 2854W
Oct 17 16:01:57 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:57 ----
Oct 17 16:01:57 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:57 pv power: 3118W
Oct 17 16:01:57 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:57 battery soc: 53%
Oct 17 16:01:57 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:57 battery power: 2725W
Oct 17 16:01:57 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:57 grid power: 24W
Oct 17 16:01:57 raspi4 evcc[30747]: [site  ] DEBUG 2023/10/17 16:01:57 site power: 2949W

What type of operating system are you running?
Linux
Version
0.121.0

Hello!
I think your configuration is missing the definition of mybat. However, you could add a scale: -1 to the definition in order to change the sign of the values. My battery definition looks like this:
  - name: storage1
    type: custom
    power:
      source: mqtt
      topic: modbus/power/sun2000/storage/1
      jq: .fields.storage_charge_discharge_power
      scale: -1
    soc:
      source: mqtt
      topic: modbus/power/sun2000/storage/1
      jq: .fields.storage_state_of_capacity
    capacity: 10

Hopefully it solves your problem.
Best regards
jens

Hello Jens,
thanks for the quick answer.
I will add scale -1 to my config.
Cheers, Pete


[cocoon] Authorize agent failed

The authorize-agent API is broken at the moment.

/cc @godofredoc @keyonghan @CaseyHillers

There are no logs suggesting this is happening at server side, can we get logs from the client side

Confirmed backend API works.

Yes. It is okay to change either side.


fabric-shim incorrectly implements interface ChaincodeStub from fabric-shim-api

(copied from https://jira.hyperledger.org/browse/BE-882)
I'm using TS and just upgraded to the new 2.2.2 version of fabric-shim ; getting the following error:

node_modules/fabric-shim/types/index.d.ts:89:18 - error TS2420: Class 'import("fabric-shim").ChaincodeStub' incorrectly implements interface 'import("fabric-shim-api").ChaincodeStub'.
Property 'getDateTimestamp' is missing in type 'import("fabric-shim").ChaincodeStub' but required in type 'import("fabric-shim-api").ChaincodeStub'.
89 export class ChaincodeStub implements IChaincodeStub {

node_modules/fabric-shim-api/types/index.d.ts:63:9
63 getDateTimestamp(): Date;

'getDateTimestamp' is declared here.

Hi, after updating my fabric-shim and fabric-shim-api to 2.2.2, I still receive this error. May I know if this has been published to the latest? Thanks!


Fix checkboxes in Firefox and IE/Edge

firefox doesn't allow for the input elements style to be completely overwritten
like it has been in chrome. So instead I am hiding the checkbox via opacity and
loading the checkbox as the background of the label. This has the nice side
effect of fixing an issue with Edge and svg backgrounds on input elements.
Finally, firefox is choking on # in svg data uris. escaping the url fixes
that.
closes tastejs/todomvc#1408

Finally, firefox is choking on # in svg data uris. escaping the url fixes
that.

I'd prefer we not do this. It makes the SVG totally unreadable. Is there a Firefox bug ticket for this?

Nice work @patrickkettner! :)

Also will close https://github.com/tastejs/todomvc/issues/1259
thanks a million @patrickkettner :+1: :+1: :+1: :+1: :+1:  :rocket:

@sindresorhus just escaping the # works too. I reduced it to just that bit. Not 100% intuitive (should inline comments be added?). Couldn't find a relevant FF bug, but I planned on opening one this afternoon.

@patrickkettner This looks great! But it seems that the toggle-all checkbox is no longer clickable after the change.

@passy hmmm... it is for me. What browser are and framework are you testing it in?

ping @passy

pong @passy :wink:

@patrickkettner
Browsers tested:

Chrome 44.0.2403.130 on Linux
Firefox 41.0a2 (2015-08-03) on Linux
Chrome 45.0.2454.62 on Android
Safari 8.0.8 on OS X

Pardon?
On Sat, Aug 22, 2015, 5:19 PM Pascal Hartig<EMAIL_ADDRESS>wrote:

@patrickkettner https://github.com/patrickkettner
Browsers tested:

Chrome 44.0.2403.130 on Linux
Firefox 41.0a2 (2015-08-03) on Linux
Chrome 45.0.2454.62 on Android
Safari 8.0.8 on OS X

—
Reply to this email directly or view it on GitHub
https://github.com/tastejs/todomvc-app-css/pull/8#issuecomment-133755439
.

Sorry, these are all the browsers I've tried and managed to reproduce it in.

no worries, I actually tried them on all of browserstacks desktop browsers and didn't spot any issues. Haven't tried mobile, however

I am able to repro the same issues as @passy on Chrome 46 on OS X.

thanks, @arthurvr. ill check it out shortly

which projects are you testing this against?
On Sun, Aug 23, 2015 at 2:22 PM, Arthur Verschaeve<EMAIL_ADDRESS>
wrote:

I am able to repro the same issues as @passy https://github.com/passy
on Chrome 46 on OS X.
—
Reply to this email directly or view it on GitHub
https://github.com/tastejs/todomvc-app-css/pull/8#issuecomment-133892461
.

--
patrick

ping @arthurvr @passy

@patrickkettner I think I used typescript-backbone because it uses the new CSS structure.

So the reason it is broken on that particular one is because the label/input connection is broken. Its using a for attribute that is not associated with any id or name.  I would view this as a bug in the html, but I can make adjustments on the css end if y'all think this is the right thing to do

@passy @sindresorhus So the reason it is broken on that particular one is because the label/input connection is broken. Its using a for attribute that is not associated with any id or name. I would view this as a bug in the html, but I can make adjustments on the css end if y'all think this is the right thing to do

I'm pretty sure I've tried three in total. If an HTML change is required I
think that's alright. Which app does it work with unmodified so I can try
it as it is?
On Thu, Sep 10, 2015, 10:40 patrick kettner<EMAIL_ADDRESS>wrote:

@passy https://github.com/passy @sindresorhus
https://github.com/sindresorhus So the reason it is broken on that
particular one is because the label/input connection is broken. Its using a
for attribute that is not associated with any id or name. I would view this
as a bug in the html, but I can make adjustments on the css end if y'all
think this is the right thing to do
—
Reply to this email directly or view it on GitHub
https://github.com/tastejs/todomvc-app-css/pull/8#issuecomment-139168931
.

it is broken on that particular one is because the label/input connection is broken

^^ makes sense, imho we can just manually go in and introduce a line or two of CSS to resolve this per framework

@passy I am not sure where I was testing it before, but if you add id=toggle-all or name=toggle-all to the markup on the typescript-backbone example you will see it working
@samccone just to clarify, this is something that should be fixed in HTML, rather than CSS (in my opinion, that is)

Unfortunately some of the example frameworks have limitations around the DOM structure, but we will just need to enumerate all of the broken ones and list out how we will fix them.

there are frameworks that don't allow for an id?

Ping @samccone @passy

@patrickkettner Yes, let's try to get this merged, finally.

just escaping the # works too. I reduced it to just that bit. Not 100% intuitive (should inline comments be added?). Couldn't find a relevant FF bug, but I planned on opening one this afternoon.

There needs to be a link to an existing or new FF bug ticket as an inline comment.

I tried this change with the Backbone app and compared with existing CSS and noticed a few incorrect changes:

The toggle all button moved. Make sure it's in the exact same spot.
Long lines are no longer wrapped.

Someone needs to test this in IE and latest Edge and confirm it's working fine there. // @jdalton

As for the broken toggle-all connection, we can just make this a major version in this package, and ensure we also update https://github.com/tastejs/todomvc-app-template/blob/master/index.html (Submitting a PR there with a fix would help move this along)

@sindresorhus thank you for taking the time to look at this
so, ironically, reducing the escaped value for Firefox broken it for Edge and IE. They require the full value to be escaped. There is an open bug to fix this, which I have marked as highly important internally due to todo's reliance (amongst others) on it. As a result I reverted the reduced escaping back to the full escape.
I also created a firefox bug for the hash issue, which is also commented on in the css.
The long lines were a type on my part ("pre" !== "pre-wrap"), which was later changed in master by using word-break: break-all. It is now also fixed
I fixed the placement of the toggle all button by tweaking the absolute positioning.
As for the toggle-all not being clickable, I am not able to reproduce it. If it is reproducible anywhere, it would be due to that demo having broken html (which I would be happy to PR a fix for, if anyone finds it).
Let me know if there is anything else I can do to get this merged!

ping @samccone @sindresorhus

I tried your changes with the Backbone example and the template and now the text goes over the checkbox.

Can you please test your changes against the template or the Backbone example? I say this in the kindest way possible, but I could not care less about this change and there are so many other things I rather do than go back-and-forth on this PR :)

apologies - that did not occur in typescript-backbone. updated accordingly

Thank you! Glad to see this finally merged :)

🎉 🎉 🎉


feat(bindings/cpp): expose reader

Explanation
std::istream is more like BufRead in rust, so I expose struct Reader(BufReader<od::BlockingReader>). Otherwise, we need to impl a BufReader in c++ which will bring more unsafe code and it's more difficult to maintain.
std::streambuf use three following pointers to track buffer state. c++ side needs to update these pointers with rust buffer state. My implementation is to call fill_buf and seek in needed and assign buffer result to the three pointers. And we call consume in the next fill_buf and seek operation to update c++ info for rust side.

I used to think we can expose something like this: https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/reference/basic_random_access_file.html to user.

The reader implementation mimics gcs sdk. It only uses std to provide a reader suitable for std::istream.
If we use boost to provide a more high-level API. The Input-seekable device of iostream library seems better. asio::basic_file seems not suitable to derive and make custom io file.

If we use boost to provide a more high-level API.

Yes, I prefer to have a more high-level API. OpenDAL's Reader is not a underlying file object and can't be operated as a file.

What makes me feel the most uneasy is the direction of our cpp binding. Let's revisit the VISION for our opendal binding: to provide a native experience and easier-to-maintain bindings based on opendal.

Naitve Experience: Makes OpenDAL looks like written in Cpp
Easier to maintain: Make maintainers for both rust core and cpp bindings happy

So our bindings is composed by two parts: ffi and cpp.

ffi is used to expose rust structs to cpp structs, it's just a bridge.
cpp is used to build public API for users.

Take a naming issue as an example:

It does ok to expose as just fill_buf, but:

Users should not call fill_buf as first, it's not the public API we want to expose. (are you agree with this?)
fill_buf is confused with other APIs. I prefer to have something that opendal::ffi::reader_fill_buf, and our cpp code should call opendal::ffi::reader_fill_buf internally.

It does ok to expose as just fill_buf, but:
Users should not call fill_buf as first, it's not the public API we want to expose. (are you agree with this?)
fill_buf is confused with other APIs. I prefer to have something that opendal::ffi::reader_fill_buf, and our cpp code should call opendal::ffi::reader_fill_buf internally. (note, there are two layers here, we should not expose ffi to users directly)

We don't expose fill_buf as public API.
our public headers don't inlcude lib.rs.h. So idealy, user won't see or use anything in opendal::ffi namesapce inlucing all functions of Reader. If users try using it according to some magic ways, we don't have any ways to avoid it.
Although we show the definition of Reader in opendal.hpp, our users can't get a Reader by any normal ways. What user will use is ReaderStream, all functions about it are same with std::istream.

Although we show the definition of Reader in opendal.hpp, our users can't get a Reader by any normal ways. What user will use is ReaderStream, all functions about it are same with std::istream.

Great! Can we organize them in a better way so that we can know the bounary?

I use boost iostreams library to make the API look better.
Update:

reader() will return Reader type to provide basic read and seek function. If users don't want iostream to make a buffer read, they can use Reader directly.
We use boost iostreams library to deal with all operations about buffer. This can significantly reduce maintain difficulty.
rename original Reader to InternalReader and move it into current Reader definition. Users now can have a clearer idea of what type they need.

@Xuanwo Could you make review again? Previously, I didn't notice boost iostreams library. All low-level details are completed by ourselves which results some APIs aren't easy to use and maintain. With boost iostreams library, I think most problems previously mentioned are solved.


Update ug with latest commads

Have update the format for findCuisinse, findPrice, findLocation with the -r command and changed the name of the field phone to price for the add command.

Codecov Report

Merging #79 (d394267) into master (a6bbe56) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #79   +/-   ##
=========================================
  Coverage     54.45%   54.45%
  Complexity      429      429
=========================================
  Files            92       92
  Lines          1750     1750
  Branches        205      205
=========================================
  Hits            953      953
  Misses          747      747
  Partials         50       50

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


CMake doesn't create coin-default.cfg or install the coin-config script

Original report by Bruce Lacey (Bitbucket: bblacey, GitHub: bblacey).

Many packages rely upon coin-config, such as pivy, to determine the coin installation configuration.  Recently, I updated the FreeCAD builds to build against tip #035e53e53730 using CMake however pivy would not run because coin-config was not installed.  To work around the problem, I modified the coin formula to perform a separate ./configure step followed by a make coin-default.cfg.   A much better solution would be to add the CMake scripts to install coin-config and create and install the requisite coin-default.cfg.  This should be a straight-forward configure_file() of a new coin.cfg.in that uses the proper CMake variables.

For me, building from master, coin-config doesn't return anything:
root@habenula:/opt/quarantine/brain-view2/install# cat ./share/Coin/conf/coin-default.cfg
# prefix is determined in coin-config, making the package "movable"
# prefix=""
host=""
exec_prefix=""
version="4.0.1"
cflags=""
cppflags=""
cxxflags=""
ldflags=""
libs=""
msvcrt=""
datadir=""
includedir=""
frameworkdir=""
htmldir=""
compiler=""
objext=""
have_3ds_import=ON
have_vrml97=ON
have_sound=ON
have_superglu=
have_threads=1
have_threadsafe=
compiler_is_gcc=
> coin-config --includedir

> coin-config --ldflags


It takes us to last chat instead of previous page when choosing user on Request money page

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open website > Click on plus icon > Request money > Enter sum and continue > Choose user > Click on username > Click on Message user... > Click on back button

Expected Result:
It takes us to last chat instead of previous page when choosing user on Request money page
Actual Result:
It should take us to previous page instead of last chat when choosing user on Request money page
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3.63-2
Reproducible in staging?: Yes
Reproducible in production?: yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
screen-capture - 2023-08-29T122225.310.webm
https://github.com/Expensify/App/assets/38435837/9c1e6773-8af4-4c56-98a5-9dd0922d5963
Expensify/Expensify Issue URL:
Issue reported by: @mahmudjontoraqulov
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1693293735435909
View all open jobs on GitHub

Proposal
Please state again the problem we are trying to solve in this issue.
It takes us to last chat instead of previous page when choosing user on Request money page.
What is the cause of this issue?
If click "message user...", Report.navigateToAndOpenReportWithAccountIDs is called, and in this function Navigation.dismissModal is called.
https://github.com/Expensify/App/blob/cbda2b03824d9b125ec6ab19e87ff533bea1b22f/src/libs/actions/Report.js#L594
In Navigation.dismissModal, app replace last navigation route (ie RightModalNavigator) with report route (ie CentralPaneNavigator).
https://github.com/Expensify/App/blob/cbda2b03824d9b125ec6ab19e87ff533bea1b22f/src/libs/Navigation/Navigation.js#L171
So RightModalNavigator will be removed in navigation stack, and then it takes us to last chat when pressing back button.
What changes do you think we should make to solve the problem?
We can call Navigation.navigate instead of Navigation.dismissModal in this line, because Navigation.navigate will push report route action.
    Navigation.navigate(ROUTES.getReportRoute(reportID));

What alternative solutions have you investigated? (Optional)
None.

@mountiny Is this actually a bug? I'd like another set of eyes from a react navigation expert.

This is expected, the Modal is closed and cleared from the memory when this is done. its on purpose


Added Implementation of GCD of two numbers using Euclidean Algorithm

Description

Created a function GCD to calculate the Greatest Common Divisor of two numbers 'a' and 'b' using Euclidean Algorithm.
It handles edge cases of (0,1), (1,0) and (0,0) well.

Tasks Completed

[x] Added the files gcd_euclidean_algorithm.py, gcd_euclidean_algorithm.java and gcd_euclidean_algorithm.cpp in the corresponding directory
[x] My code aligns with the specified structure.
[x] Updated RoadMap.md

Make these modifications:

Your code's logic is inconsistent. In Cpp and java, gcd(-2, -4) will give 2, but in python it will return -2. GCD means the largest number which divides both the numbers, so answer of gcd(-2, -4) should be equal to 2.
Gcd(0,0) = 0. Don't return, as -1

I have made the required changes.

Good work


Speech Recognition Accuracy Degradation Over Twilio Phone Integration

I’ve noticed significantly reduced speech recognition accuracy when communicating with the model through the Twilio phone integration. For example, when I say, “How far is the moon?”, the model often interprets it as something related to “Munich in Germany.” Even after I clarify by saying, “I am talking about the moon,” it continues to misunderstand and talk about Munich.
When I interact with the model using the OpenAI Playground’s real-time API (both in English and Russian), the speech-to-text works flawlessly. My spoken words are understood accurately, and I don’t experience this confusion. Similarly, in the ChatGPT app, the speech recognition also performs well.
Given that the performance difference is so pronounced, I suspect the issue is related to the audio quality or transmission when using Twilio’s phone integration. It seems like the model struggles to correctly interpret spoken words despite them being understood perfectly in other environments.

How do you have your audio configured? Are you using your own stack, or a hybrid of Studio and other Twilio tools?

I am testing by running this app without changes

I also tested Eleven Labs in combination with Twilio, and there are no problems there.

it is weird that it sometimes transcribe my speach to text correctly but responding with something unrelated. for example:
assistant: Hello! How can I assist you today?
user: Hello, can you please tell me a joke?
assistant: Of course! What kind of help do you need with your job? Are you looking for job search tips, resume advice, or something else?

it is weird that it sometimes transcribe my speach to text correctly but responding with something unrelated. for example:
assistant: Hello! Thank you for calling. How can I help you today?
user: Oh, please tell me a joke.

assistant: Of course! What do you need help with today?
user: A joke.

assistant: Could you please provide more details or specify what you'd like to know about? I'm here to help with any questions you have.
user: And that's a joke.

assistant: I'm sorry to hear about your loss. If you need support or have specific questions during this difficult time, please let me know how I can assist you.
user: No, I just wanted to hear a joke.

assistant: Sure, I’d be happy to share a joke with you! Why did the scarecrow win an award? Because he was outstanding in his field!

I think it uses different models for transcript and for completion. meaning what it provides as transcript is not necessary what model gets


greetd minimalism

Ideas
The below triplet is a really refreshing extremely minimal greeter solution written in rust, that I'd like to adopt in my environments. I might eventually get around and package them myself, but if somebody is interested in beating me to it, it will be an easy win. :smile:
Requests

https://sr.ht/~kennylevinsen/greetd/
https://git.sr.ht/~kennylevinsen/wlgreet
https://github.com/apognu/tuigreet

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

All of these and more are now available on unstable

@blaggacao Can the unstable modules be imported as supplementary modules to complement the stable ones?

@Narice You would be pulling the corresponding packages in ./overlays.overrides.nix, as for the modules, you can use latestModulePath which is an automagic specialArgs in fup for the input channel named latest. So to pull in modules, it would be something like:
{latestModulePath}: {
    imports = [ "${latestModulePath}/path/to/module.nix" ];
}

it can be that you also need to disable some current stable module with disabledModules if there are conflicts. Not always are those modules compatible tough, so chances are somewhat 50/50.
fup-implementation for reference.
Let me know how it goes. :wink:

Nice, Thanks!
Do you think we can close this issue?

Yeah I don't think we should encourage module creation or packaging in this repo anyways, since the whole point is to put them in your devos flake and share it.
Maybe we can create some tag for thread in GH discussions where you can share links to your content or requests for packaging/modules from others.


RuntimeError: Queue not yet published after 30 seconds

I got this error RuntimeError: Queue not yet published after 30 seconds with redis server listening to <IP_ADDRESS>:6379
when running
bundle exec rspecq --build=123 --worker=foo1 spec/models/car_spec.rb

Can you help to fix this error?

Hello! How many workers are you trying with?
This error usually means that the worker that won the race to publish the queue, haven't done so after 30". This usually means that that worker exited with an error. Can you verify that's the case?
Could you try the above command with a single worker?
$ bundle exec rspecq --build=$RANDOM --worker=$RANDOM spec/models/car_spec.rb

Closing this due to inactivity. Feel free to follow up with the information requested and we'll gladly re-open the issue.


Enhance -n (allow to render intervals of animations)

As the title says, simple issue. Right now -n can be used to start at a specific animation (and thus skip the prior ones). We should extend it to be able to render a specific interval of animations, so allowing it to stop rendering at a specific animation too.
Also... --start_at_animation_number is not just going to be deprecated then, it's also just obnoxiously long. What should it be called afterwards though? Keeping -n is fine but if we keep the long form... --interval? --animation_interval? --animate_interval?

You can already do that by providing two comma separated values.
-n <start>, <stop>

Is that so? Hm... yeah looks like it. We should at least fix the confusing indications. Stuff like --start_at_animation_number.

Agreed.

Should this be closed? The title is misleading apparently.

@XorUnison I will add a --from_animation_number to my PR on rewriting the config/constants setup.


pos_product_category_discount: will not work well enough with pos_cache

The module pos_cache is used for the purpose of improving load time in case of thousands of products.
The module pos_product_category_discount loads product.template (apart from the product cache) .

Loading product.template increases the load time a lot.

When pos_cache is installed, product.product is loaded last from load_server_data and loading product.template depends on products. So loading product.template will fail as there will be nothing in pos.db.product_by_id

To fix this we can add the field discount_allowed in load_server_data, something like the following:
    load_server_data: function () {
        var self = this;
        var product_index = _.findIndex(this.models, function (model) {
            return model.model === "product.product";
        });
        var product_model = this.models[product_index];
        var product_fields = product_model.fields;
        product_fields.push('discount_allowed');
        product_fields.push('product_variant_ids');
        product_fields.push('write_date');
        return posmodel_super.load_server_data.call(this, arguments);
    },

Thank you

Hello, @dek-odoo
I fixed the issue. You can check it https://github.com/it-projects-llc/pos-addons/pull/493

:+1: @GabbasovDinar


chore(readme.md): reviewed features list for better readability

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


Implement Events

[x] Event
[ ] VisualEvent
[ ] PositionalAppearance
[ ] Keystroke

Depends on #31


Set default theme to auto

Update package.json to Set default theme to auto
This allows the extension to automatically respect the user's preference for light or dark mode.

I'm not sure this make sense for excalidraw drawings.
The website default to light mode, even when the system theme is dark.

I see, then it wasn’t an oversight in these settings, but rather a design choice.
I wonder what the advantage of editing in light mode is, despite the user having a preconfigured preference for dark mode?

I think it was set to auto at first, but it confused some users (as they did not know how to configure it to appear the same way as in the website).
I think people actively searching for the dark mode will be able to find it. I'll try to get some feedback from the team on this.

Got it, that makes sense to maintain parity between website and extension behavior. Although I would say the website version should also respect the browsers theme preferences. Maybe that’s a separate discussion.
Is there a technical limitation that prevents setting Dark Mode the setting using the hamburger menu like on the website?

I don't think so, the extension was created before it the excalidraw component started supporting this kind of customisation.
It is definitely possible to add support for it now!

Cool. I use this tool a lot in my day job, so I would love to contribute this when I can find the time.
Basically, my physical laptop is a very locked down device and does not allow access to the internet, but it does have VS Code and allows extensions to be installed.
Although I can access remote machines via RDP which can access the internet and use Excalidraw for web, I then have to deal with RDP lag while designing.
This extension has been a wonderful solution for me, so thank you for all your work on it.

Thanks for the nice words! Contributions are definitely welcome :)


Multi version

This PR enables support for selecting a package list version. Currently supported are:

8.13
8.12
dev

Reenabling the dev branch seems to have issues on Mac, so let's see what CI says ...
@gares : except for the issues with the dev branch, this is very close to final.

If switch names support +, I would really recommend using it before the Coq version to distinguish it from the platform version.

If switch names support +, I would really recommend using it before the Coq version to distinguish it from the platform version.

Yes, I thought that the . gets hard to read. I will try "+". I also thought about using "_", but I like "+".

One issue with + than I didn't realize when commenting is that if we keep using it for beta versions there might be switches with two + signs that do not mean the same thing (2021.07+beta1+8.13). So we should either stop using it for beta versions (2021.07beta1+8.13) or use a different symbol for the Coq version (2021.07+beta1_8.13).

So how about "__coq-platform_2021.02.1_8.13" so using "_" also es separator between coq-platform and its version? Btw. It used to be "coq-platform.2021.02.1". I decided to start with two underscores as classical prefix for "system reserved names in a user name space" but don't have strong opinions about this.

Yes, your proposal looks pretty great!

Overall it looks ok, but since you have coq_packages.8.12.sh I guess I don't get exactly what the plan is. 2021.02.x was, in my mental model, pivoted on Coq 8.13.x and, at least for some packages, there is no choice (coq-elpi 1.9 does not work on 8.12, you need 1.8 for that). Maybe you want to have coq_package_2021.02.x.sh  and, say, coq_packages_2021.06.x.sh in the same repo, each pivoted on its coq version, but this PR fixed one platform version and multiple package lists.
Can you clarify this and how git branches would then be used?

@gares: For packages which did exist for older versions of Coq the idea is to add them to the respective package list - for packages which are new for Coq 8.X they are only added from 8.X onward. So the idea is that the package lists do increase also for old versions.
After pondering over this for a while I think that this is the easiest to maintain and most useful method for users.
I am not yet sure what the final branch structure will be. Most likely this will become the master branch and we release from the master branch since with a multi-version branch there is no good reason for doing releases from older Platform versions.

I'm not so sure. What sould 2021.02.1 mean if by picking 8.12 or 8.13 the versions of the packages change?

I'm not so sure I get it. What would 2021.02.1 mean if by picking 8.12 or 8.13 the versions of the packages change?

Well yes, one has to say 2021.02.1_8.12 or 2021.02.1_8.13 or 2021.02.1_dev and probably would use 2021.02.1 as abbreviation for 2021.02.1_8.13.

Maybe It's just a detail, but I'd prefer 2021.02.1 (for 8.13) and 2021.02.1_8.12 for the "backport" thing (2021.02.1~8.12 if made an opam package, so that it is < than the one without a coq version). If only because we can't change the version schema every day ;-)

It is an important detail and I agree that we should fix the naming now. IMO it is perfectly agreeable to say "The Coq Platform" is the one with the latest released Coq and then there are "compatibility versions" with newer (dev - maybe some day even a beta) or older Coq. So shall we go with that?
And indeed it does make sense to come up with a naming scheme, which would work as a name for opam packages as well - I didn't think about it.
I guess one would have a dev Coq Platform package in extra-dev but everything else should work naturally. So I guess if we use the short name for the latest release, the previous versions must be named e.g. "~8.12"? How about the dev version?

IMO it is perfectly agreeable to say "The Coq Platform" is the one with the latest released Coq and then there are "compatibility versions" with newer (dev - maybe some day even a beta) or older Coq. So shall we go with that?

:+1:

And indeed it does make sense to come up with a naming scheme, which would work as a name for opam packages as well - I didn't think about it.

I'm actually wondering if we will ever want to provide a meta opam package for the Coq platform. The scripts as they are, with their management of opam switches, are pretty convincing. In particular, the Coq platform pins the version of the underlying OCaml compiler. opam packages for the Coq platform would probably be worth the trouble only if we were to relax this constraint, right?

I'm actually wondering if we will ever want to provide a meta opam package for the Coq platform.

There are currently a few issues with this:

I have patch opam packages required for Windows which I couldn't get accepted upstream. Likely the best fix for this would be to create a fixed gtk-sourceview package for cygwin. There might be other ways around this after introducing the local pkg-config concept in opam.
I have .dev packages for OCaml stuff (menhir, gappa) and main opam doesn't have an extra-dev concept. I guess here the best solution would be to add them to Coq's extra-dev.
The system sanity checks are helpful - on all systems. One would have to get some of this into opam or create a "check my system sanity" opam package.

Also I think it would help to get the Windows opam repo merged into the main opam repo - as is the patch repo is required from time to time, since without it merge delays are not manageable. And I don't think it would be good to change recommendations every other release.
So this is a goal, but not short term.

So the final conclusion is to name the switches:

__coq-platform.2021.02.1
__coq-platform.2021.02.1~8.12
__coq-platform.2021.02.1~dev

provided this works. Note that I went back to have a dot between coq-platform and the version, because this is what one would use with opam install as well. So the package name would be the same except that the two underscores are removed. I would like to keep this, because as I said this are auto generated names in a user name space.

Also I think it would help to get the Windows opam repo merged into the main opam repo - as is the patch repo is required from time to time, since without it merge delays are not manageable. And I don't think it would be good to change recommendations every other release.

About this, have you noted #92?

@gares : I am looking at the snap file and wondering why it doesn't use the full coq platforms script. I guess it is required to install opam on its own, e.g. cause it needs to live in a specific folder, but one could still setup opam upfront and let the script setup the switch and the repos and do all the rest. Is there a good reason why you didn't do that?

I think it does for the build process:
https://github.com/coq/platform/blob/2021.02/linux/snap/snapcraft.yaml.in#L23
It uses bits and pieces of it to generate the package description, IMO. I did that before realizing it is not updated automatically.
Is this what you are talking about?

@gares : thanks - O just didn't understand it. I will fix it then. I guess one can in a later PR change it such that it uses the same packaging logic as Windows and Mac, so that it would also work with manually extended opam switches.

The best would be to:

minimal sed on snapcraft.yml.in with no need to have opam & co around, just set the version string and the platform script flags
from the build step of the snap

run the platform script
run a snap specific installation script (now inlined and not shared with win/mac, e.g. the blacklist of files etc)
print the package description for the publishing step (similar code to the one generating html for mac)

Just in case, we can't run the main platform script outside snap, and then copy the files inside, because it is snap which sets up gtk & co, and it has to stay that way, since installing the snap pulls in the gnome "platform" snap as a dependency.
The snap really contains an opam root, properly trimmed. We can take the files from there and putting them in a mirror layout, as we do in the other install scripts, if it comes handy to share more code with win/mac it is welcome, but if not there is really no need for it.

let me merge some commits in hierarchy-builder/coq-master

~let me merge some commits in hierarchy-builder/coq-master~ No, this is not the problem. I believe the problem is the overlay which is incomplete.

Yes, I copied the opam file from hierarchy-builder master without much thinking. Thanks for the fix!

@gares : as discussed, I won't merge this into 2021.02 but instead push this as master and make this the new main branch then.

OK, works for me

maybe call this branch main (the new default on github)

Thanks for the hint - I will call it main!

The snap is still disabled. What was the problem there?

It is not compatible with the multi version stuff. I fixed a few things (e.g. opam repo layout) but not all. E.g. one needs to be able to recover the name of the version file from the switch name and the like. So the names / interfaces of some scripts the snap packager uses have changed. It shouldn't be hard to fix (for me since I know what changed), but I didn't have time over the weekend.

This went into the main branch and won't be merged.


[SparkR][BUILD]:ignore cran-check.out under R folder

What changes were proposed in this pull request?
(Please fill in changes proposed in this fix)
R add cran check which will generate the cran-check.out. This file should be ignored in git.
How was this patch tested?
(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
Manual test it. Run clean test and git status to make sure the file is not included in git.

Test build #64300 has started for PR 14774 at commit f5b781c.

Test build #64300 has finished for PR 14774 at commit f5b781c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/64300/
Test PASSed.

Merged build finished. Test PASSed.

LGTM. Thanks @wangmiao1981


Element type is invalid

What version of Remix are you using?
2.0.0
Are all your remix dependencies & dev-dependencies using the same version?

[X] Yes

Steps to Reproduce

Create remix project by run npx create-remix@latest
Try to use Material Design Icons. You can read the doc

It works in npx create-react-app project, but not in remix. So I'm not sure if it's a bug in remix?
Expected Behavior
Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.
Actual Behavior
Render icons correctly

Could you provide a minimal reproduction in Stackblitz or a github repo?

@brophdawg11 Yes, you can try this https://github.com/Ardear/Remix

Seeing the same errors:

Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and name

I am using Remix + Vite.
This appears to be happening when using HMR and React.lazy.

https://github.com/remix-run/remix/discussions/8153#discussioncomment-7693961
^This tip helped.
I've moved my components to .client.ts and replace React.lazy with ClientOnly from remix-uitls, and the issue has gone away.

I still think there is an issue specific to React.lazy. Someone in the chat suggested that this could be related to "ESM/CJS interop" in Vite/Remix.

I get this error when importing .client.tsx files when using vite
Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

https://github.com/remix-run/remix/issues/8378


CloseButton no longer working.

Hi Peter
A day or two back I built a mp for the rpi picoW using what I think is a version of the V1.24 preview ( I download the mp by using  git clone https://github.com/micropython/micropython.git --branch master.   I froze in the mp-touch and the mqtt_as by adding the latest files copied from your repository to the manifest.   (as I had previously done a couple of months ago)
All seems to work OK except the CloseButton will not close the program.   It will, as before, close a sub screen and return to the base screen, but when the CloseButton is clicked on the base screen everything comes to a halt but I don't get back to the REPL prompts as I used to.  (running from Thonny) The only recourse is to power cycle the picoW.
I have the previous build so I can revert so its not a pressing issue, but I was wondering if you have any idea of what may be amiss or the best way to track this down.
Thanks.

Please could you try one of the demo scripts to determine whether the close button works correctly (e.g. simple.py).
I have had problems with the close button not responding to touch, but that doesn't sound like what's happening in your case: it sounds as if it's responding but not behaving correctly.
Just FYI, causes resulted from the small size of the button and its location at the extreme limits of the screen:

Imprecise calibration of the touch overlay.
Inaccurate touches (fixed by using a stylus).


Add Github url in emails

Coverage remained the same at 47.364% when pulling 69d64b8da79c2d026beb88c598a8bdb47a12974f on calixteman:github_link into d49e6231e2ad42c898cec8143a5d4e1c97860359 on mozilla:master.


[Integration] Podman preset tests

Relates to: Issue #2920
This PR sets up integration tests to work with podman preset on all 3 platforms. The test itself is barely populated, but this will be remedied when we pull in some tests from the podman e2e suite.

@jsliacan Looking at the job logs, the CI failures seems to be because it can't find the correct podman bundle and trying to run setup with the libvirt bundle.
level=info msg="Getting bundle for the CRC executable"
[387](https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/code-ready_crc/3081/pull-ci-code-ready-crc-main-integration-crc/1514175911950290944#1:build-log.txt%3A387)
        level=debug msg="Ensuring directory /home/packer/.crc/cache exists"
[388](https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/code-ready_crc/3081/pull-ci-code-ready-crc-main-integration-crc/1514175911950290944#1:build-log.txt%3A388)
        crc_libvirt_4.10.6_amd64.crcbundle is not supported by this crc executable, please use crc_podman_libvirt_3.4.4_amd64.crcbundle
[389](https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/code-ready_crc/3081/pull-ci-code-ready-crc-main-integration-crc/1514175911950290944#1:build-log.txt%3A389)

Currently we can't set the "bundle" in the testing code right? its configurable using an env variable, which is fixed for the whole test run, but now since we have tests that expects two (and more..) kinds of bundles, maybe we should make this configurable from the testing code?

@anjannath yes, you're right for one PR check, both bundles will be needed. I'll have a look and suggest some changes. I'll make it a separate commit. Thanks!

@jsliacan are these tests supposed to exists along and separate from the upstream tests from podman as i think the upstream tests will be stand alone and we won't pull in actual test code to our repo?

/test e2e-crc


Import Antigen CDC XML data into database

Next steps:

figure out which data to pull from it (#52 & #53 could help scope this)
figure out how to map the pulled data into Rails classes

Completed with commit 5b2290050ea1023dd98b982cd9607b8c9553052d


C>T SNPs

Hi Devon,
Just out of curiosity, how does MethylDackel/PileOMeth handles C>T SNPs in the methylation calling? BisSNP and the newer biscuit  have the ability to distinguish the SNP from the opposite strand in directional sequencing and exclude those SNPs from the methylation calling. Is there a similar way to exclude those SNPs which are unreliable for methylation calling with MethylDackel?
Thanks!

Thanks for the question! At the moment this issue is simply ignored, due to this package having been developed in the context of in bred mice, where variants are simply not an issue. It'd be a simple enough thing to implement though, so I'll leave this here as a reminder to do so (I've actually been thinking of doing it for almost 1.5 years, but never had someone outside of my group ask me about it).

I've implemented a method to do this in the master branch, it'll be part of the next release. The method is fairly simple, though I know it's also used in at least some other tools. Namely, it looks for mismatches in the strand opposite of a C and will exclude a site (or CpG/CHG if --mergeContext is specified) if the fraction of mismatches is above some desired value (--maxVariantFrac). For obvious reasons, there's also a minimum depth required for this (--minOppositeDepth).

Thank you! I will give this a try

This is now implemented in version 0.3.0 :)


Apns HTTP2 support

I would like to use HTTP2 endpoint of APNS, are you planning to update the lib and use the apns4erl v2 or should I start my own lib?

I have no plans to add HTTPS2 at this point. I think https://github.com/codedge-llc/pigeon does HTTP2.

@chvanikoff any plans for HTTP2?

pigeon and https://github.com/codedge-llc/kadabra are Very much a work in progress. That's why I was asking.


AUR build error

#47 @aurkaxi

I updated the PKGBUILD, can you check again?
if ! yay -Qi webtorrent-cli &> /dev/null && ! npm list -g webtorrent-cli &> /dev/null; then
  echo "Installing webtorrent-cli"
  yay -S --noconfirm --needed webtorrent-cli
fi

Yes, it works now, thanks in advance.

This is not the proper way to do things. Simply add webtorrent-cli to the list of dependencies. Using yay in the PKGBUILD forces everyone to have yay to build the package.
Users of other AUR helpers, or even worse, users that do not use AUR helpers at all since they are not officially supported can't build this package.
Please, scratch this.

webtorrent-cli is from aur. We can't add aur package as dependency, can we?

You can.

❯ makepkg -si
==> Making package: botflix-git r158.a75cbd5-1 (Sun 09 Jun 2024 12:50:01 AM +06)
==> Checking runtime dependencies...
==> Installing missing dependencies...
[sudo] password for aurka:
error: target not found: webtorrent-cli
==> ERROR: 'pacman' failed to install missing dependencies.
==> Missing dependencies:
  -> npm
  -> webtorrent-cli
==> Checking buildtime dependencies...
==> ERROR: Could not resolve all dependencies.

I don't think so.

It worked. It correctly detected you are missing a dependency. Now you can install it, instead of forcing me to use a specific AUR helper.


Add Radio Bremen

URL taken from: https://www.butenunbinnen.de/livestream/
Logo Taken from: https://commons.wikimedia.org/wiki/File:Logo_Radio_Bremen.svg

Thank you very much for this pull request! I'll hopefully be able to look into it the next days.


Support ClickHouse and Kafka disk autoscaling

Code is fine.
However something wrong with golangci-linter. Im gonna take a look.

Fixed here


print "Unable to open database, sleeping" to stderr

With current master aptly prints the error "Unable to open database, sleeping" to stdout, next to the real output. This makes it impossible to directly use the output in a shell script.
Possible Implementation
Change https://github.com/smira/aptly/blob/master/context/context.go#L265 to print to stderr. (I don't have the Go skills right now to do it).
Your Environment
Current aptly master

Thanks, I will get it fixed in a few!


Unit testing

Blackduck scan failure details
Summary: 0 violations, 0 files pending approval, 1 file pending identification.

Protex Server Path: /home/blackduck/github/Lightning-CLI/237/rdkcentral/Lightning-CLI

Commit: ba08ff14501c8e0ca28a75a0986f265bef0e133c

Report detail: gist

This code contains a compliance violation.  I will have to open a ticket to add the extra credit required.  Please do not merge code with a Blackduck issue before the CMF team have had a chance to consider what's wrong.

Hi Michiel:
I opened a BD (internal CMF) ticket for this, but I think the snippet is from Facebook's Jest, so the credit is:
runSequence.js, before line 20:
* Copyright (c) Meta Platforms, Inc. and affiliates.
* Licensed under the MIT license.

In LICENSE, please append an MIT license (with generic YEAR and COPYRIGHT HOLDER).
Also, append to NOTICE:
Jest is:
Copyright (c) Meta Platforms, Inc. and affiliates.
Licensed under the MIT License

If you think it is somewhere else, please tell me.  I was looking at:
https://github.com/jestjs/jest/blob/main/e2e/worker-restart-before-send/testSequencer.js
All new code files should have headers as well but the Blackduck match should be fixed to comply with its license.  (Agreed it isn't a lot of code.)
Thanks,
Martin


Upgrade to normalize v4

https://github.com/necolas/normalize.css/blob/master/CHANGELOG.md#400-march-19-2016

v2.19.0


Improve with AsyncState type definition

Issue
The AsyncState type could return an object with loading being false, but no value nor error.
This makes handling the value returned by e.g. useAsync quite difficult:

Code used for easy copy/paste

import { useAsync } from 'react-use';

const getPromise = async (): Promise<number> => 6;

const test = (): string => {
  const state = useAsync(getPromise, []);
  if (state.loading === true) {
    return 'loading...';
  }
  if (state.error !== undefined) {
    return state.error.message;
  }

  const result = 7 * state.value;
  return `${result}`;
};

export default test;

In the above example, the loading and error cases have already been ruled out, so value should not be undefined, creating issues:

This makes developers test if the value is undefined or not, which is an useless test;
If the Promise was actually returning a value that could be undefined, then we have no assurance that the (undefined) value actually comes from the promise.

Related
Commit creating the issue
In https://github.com/streamich/react-use/pull/348, @NullVoxPopuli merged the type AsyncState in useAsync with the one in useAsyncFn. However, there were different!
*** useAsync_type.ts
--- useAsyncFn_type.ts
***************
*** 1,7 ****
  export type AsyncState<T> =
    | {
!       loading: true;
        error?: undefined;
        value?: undefined;
      }
    | {
--- 1,7 ----
  export type AsyncState<T> =
    | {
!       loading: boolean;
        error?: undefined;
        value?: undefined;
      }
    | {

The fact that loading was true and not boolean solved the issue in useAsync, but it is not possible in useAsyncFn because of the initial value.
Possibly related issue
@wardoost 's screenshot in https://github.com/streamich/react-use/issues/190#issuecomment-478305429 seems related even though the issue may not be
Proposed solution
In this PR, I revert the diff above in the type AsyncState, and overload the type of useAsyncFn to  make the best of both worlds.
In other words, for the type AsyncState<T> if loading is false, then either error (of type Error) or value (of type T) has to be specified.

Breaking change
Before this PR, it was possible to call useAsyncFn with an initalState set to { loading: false }, although probably nobody did because it was the default if no initialState was provided.
To replicate the behaviour, you can either:

use { loading: false, value: undefined } as the initialState
do not specify initialState at all, since it is the default value

I would argue that this breaking change is minor as people in that case would have probably chosen to not specify initialState already.

In your example, it seems you can replace this line
const result = 7 * state.value;

by this (not ! non-null assertion):
const result = 7 * state.value!;

would that solve your case?

would that solve your case?

Thank you for your reply! That solves the typing issue (an other idea would have been testing if value is undefined), but does not solve the issue at hand. I would argue that it's more like a workaround against a weak typing of the returned value.
See, as a TypeScript user of useAsync, I don't want to look at the way useAsync is implemented, I should be able to rely exclusively on docs and types.

On one hand, reading the doc, I would have assumed that if loading is false and error is undefined, then the value is returned directly.
On the other hand, looking at the returned types let me think that there is a case in which useAsync returns an object { loading: false, error: undefined, value: undefined }, and as a result I should test if value is undefined as well (but when that case arises and what to do in that case is unclear).

So I would say that the docs and the typing disagree, which is confusing for the users of useAsync: which one to believe?
To conclude with, for me this is a bug in the typing, so that's why I'm submitting a PR to fix it :relaxed:

Side note: I have updated my code to have better types for AsyncFn as well (+ rebased on master).

I came across this issue as well, and ended up writing my own type definition that I just cast the result to.
type AsyncState<T> =
  | {
      loading: true;
    }
  | {
      loading: false;
      error: Error;
      value: undefined;
    }
  | {
      loading: false;
      error: undefined;
      value: T;
    };

The main difference between this and your solution is the loading state doesn't have error or undefined, which better matches the implementation. I've also set them to undefined in the opposite cases, which means the compiler doesn't yell at you when you do state.value.

The main difference between this and your solution is the loading state doesn't have error or undefined, which better matches the implementation.

The reason there is, is so that we could do type destructuring:
const { loading, error, value } = useAsync(…);

I've also set them explicitly to undefined, because ?: undefined looks weird to me

This is to allow the following: { loading: false, value: 42 } without specifying error: undefined for example.

Huh, I hadn't considered those. I generally avoid destructuring (just personal taste, but I have been using t a bit more lately), but the ?: use case is just something I hadn't considered.

IMO there should be one more state falg like loaded or loading should be renamed to loaded and has boolean | null type, where:

null - loading not started
false - loading strated but not done
true - loading done

Because current state signature has ambiguous loaded: false state meaning both, not started and done states;

@streamich any thought on @xobotyi 's comment?
If I understand correctly the proposition: returned values of useAsyncFn:

initial value (assuming no initialState argument`):

{
  loaded: false,
  loading: false,
}

once the callback has been called:

{
  loaded: false,
  loading: true,
}

if the callback resolves:

{
  loaded: true,
  loading: false,
  value: 42,
}

if the callback rejects:

{
  loaded: true,
  loading: false,
  error: new Error('Something went wrong'),
}

@xobotyi, @Rogdham Only adding a boolean for loaded is not enough, a promise can also throw undefined. We could add an errored key to fix this, which makes the hook's API bigger than it needs to be. It's what is proposed in https://github.com/streamich/react-use/issues/88#issuecomment-458964715 but with different a different signature.
A status key which indicates all these different states could also work, see https://github.com/streamich/react-use/issues/88#issuecomment-458979326. This would be a breaking change but seems like the most complete solution to me.
Feel free to open a PR for this or continue the conversation in https://github.com/streamich/react-use/issues/88 as this Pr is about type definitions.

@wardoost same as throw undefined it can fulfill with undefined %)
But its still be a 'loaded:true' + 'loading:false', this one is non-breaking change that solves the problem, despite the moment that I'd done as in comment you linked if I develop that hook.

@xobotyi So we would have to add both a loaded and errored key to be able to determine if a promise throwed or resolved an undefined value as pointed out before.
It's easy to say "I would have done if I did it" especially considering the original was written back in October 2018 when hooks wasn't even released in the stable version of React. It's always best to be careful about introducing breaking changes but I think have a single status key should be up for consideration because if keeps the hook's API more clear despite being a breaking change. We could also add a status or state key to the state with 'idle' | 'pending' | 'rejected' | 'fulfilled' as possible values and keep the loading key so it's not a breaking change, add a dev warning when the loading key is used and introduce the breaking change at a later change to give devs time to update existing code.
I think we best continue the conversation on this in #88 as this PR is about type definitions.

Only adding a boolean for loaded is not enough, a promise can also throw undefined.

I did not considered that for the following reasons:

The existing type already uses Error for the error key (which will not work if a Promise rejects with a number for example);
I use the no-throw-literal ESLint rule which checks that Promises rejects Errors: ”It is considered good practice to only throw the Error object itself or an object using the Error object as base objects for user-defined exceptions.” I'm not sure if this is a well-established practice, or if it's ok to assume that in any way.

What do you think @wardoost? Especially concerning the point 1 above, i.e. existing type already asserts that Promise reject Errors.

TLDR; maybe the types could be something like this:
export type AsyncState<T, E = Error> =
  | {
      state: 'pending';
      loading: true;
      error?: unknown;
      value?: unknown;
    }
  | {
      state: 'rejected';
      loading: false;
      error: E;
      value?: unknown;
    }
  | {
      state: 'fulfilled';
      loading: false;
      error?: unknown;
      value: T;
    };

export type AsyncStateFn<T, E = Error> =
  | {
      state: 'idle';
      loading?: unknown;
      error?: unknown;
      value?: unknown;
    }
  | AsyncState<T, E>;

The initial API for this hook was probably inspired by Apollo Client, which returns { loading, error, data }, this hook swapped data for value, which led to { loading, error, value } tuple, which I believe still should work fine for the useAsync hook (possibly with some tweaks). It is the useAsyncFn hook that is more complex.

The original useAsync hook (and still now) executes the asynchronous function "immediately", which means that { loading, error } should be enough to capture the state of the asynchronous function. Eventually, useAsyncFn hook was added, which does not execute the asynchronous function immediately, but instead user can choose when to call it. This adds extra state, which currently, I believe, is not fully captured by the { loading, error } tuple. Hence, for example @xobotyi, has proposed to add an extra { loaded } state.

Currently, useAsync uses useAsyncFn hook internally, I wonder if useAsyncFn should use useAsync instead, or maybe even the two hooks could be separate.

The error property does not necessarily need to be of type Error, maybe that's why in the original implementation it was Error | any. We should still allow for the possibility of error not being of type Error, maybe using Error as the default type, but allowing user to overwrite it, like const useAsync = <E = Error>() => { ... }.

Another case which current useAsync implementation does not really cover (as mentioned by @wardoost  and others) is that if error itself is of type undefined. Imagine the asynchronous function throws undefined, the state would be { loading: false, error: undefined, value: undefined }. Did promise resolve or reject? One could, of course, check if the undefined values on error and value are own-properties or missing keys, but that is 🤯. So, even the state of useAsync hook today probably does not capture correctly all cases.

Probably { loading, error } captures the state of the operation correctly in the Apollo Client, as their error is always of type ApolloError, but in react-use we need to deal with all possible cases. Hence maybe we could add a more specific state property, which would precisely identify the state; error and value would not be used for state identification—those would just hold data. Also, we could still keep loading (but deprecated), so it wold not be a breaking change (like suggested by @wardoost and possibly name it status, not state).

As mentioned by @Rogdham, we should keep all properties in all unioned interfaces that create the AsyncState type, so we can do destructuring const { loading, value, error } = useAsync(...).

Maybe we could add onFinally effect like suggested here.

There is useAsyncRetry hook, but no useAsyncFnRetry; I wonder if we need one.


NO_PUBKEY - Unable to install az on Ubuntu 18.04

I'm trying to install using the instructions posted here: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view=azure-cli-latest
However, I get something like the following:
Err:5 https://packages.microsoft.com/repos/azure-cli bionic InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EB3E94ADBE1229CF
W: http://us.archive.ubuntu.com/ubuntu/dists/bionic/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/microsoft.asc.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: https://packages.microsoft.com/repos/azure-cli/dists/bionic/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/microsoft.asc.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: GPG error: https://packages.microsoft.com/repos/azure-cli bionic InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EB3E94ADBE1229CF
E: The repository 'https://packages.microsoft.com/repos/azure-cli bionic InRelease' is not signed.

I'm running Ubuntu 18.04
Here's a similar issue: https://github.com/Azure/azure-cli/issues/6383
@dtzar was able to update the key last time. The fix here is probably similar

This is an internal issue at my work, closing


Question: what is the option 'Detect Type Swap Hold Key' for?

Question: what is the option 'Detect Type Swap Hold Key' for?
This is probably the only feature left that I do not understand.
Thanks

A feature is very great
it swaps between the input mouseover text type, but you have to keep both shortcuts at the same time
for example :
Show Tooltip When: Shift Left
Mouseover Text Type Swap Key: Ctrl left
Mouseover Text Type: Container
Now if you hold shift and control at the same time , it uses Word instead of Container, that is, it does not translate the entire Container,It only translates the word the mouse is hovering over.
@ttop32
It would be great if it also said synonyms in "Word mode" (such as simple translate extension) because every word has several meanings and seeing only one meaning sometimes does not solve the problem.

Thank you. Very nice.

It would be great if it also said synonyms in "Word mode" (such as simple translate extension) because every word has several meanings and seeing only one meaning sometimes does not solve the problem.

Absolutely!


[Revalidation] Don't email customers if the package is already available

We are revalidating all packages to repository sign them. These revalidations should not email customers.

Verified on DEV by uploading a package, waiting until validations finished, deleting the validation set, disabling the ESRP submitter, and revalidating the package. No email was sent.


Fix path splitting to account for Windows paths

This fixes an issue I hit using http-server to run a simple test site, and I can see others have reported this also (e.g. https://github.com/nodeapps/http-server/issues/122 ).
Basically, path.join is used in places (such as @ line 117: url: path.join(encodeURIComponent(pathname), '/index.' + defaultExt)), and this results in backslashes in the URL on Windows.  This causes failures in the decodePathname function, as it only handles forward slashes when breaking apart the paths.  This change simply handles backslashes as well as forward slashes to split the path before trying to decode the parts.  This fixes the issue for me.
Note the line called out above (117) looks suspect also, so the correct fix may actually be here.  For example, when just running 'http-server' and requesting the root of the site ( http://localhost:8080/ ), pathname == "/".  This is URI encoded to "%2F", then path.joined to "/index.html", which on Windows results in "%2F\index.html".  Even on a forward-slash system this would result in "%2F/index.html" - which seems wrong.
I'd also note trying to run the tests with "npm test" doesn't work for me - either before or after this change.  Most tests fail with TypeError: Cannot read property 'statusCode' of undefined.  Not sure if this is Windows specific or not.  I didn't have time to investigate further.

Have just implemented on my local machine and it resolves the issue. (Windows 8 x64)


Migrate primary branch from master to main

See https://github.com/Senzing/stream-loader/issues/283

Pull requests

https://github.com/Senzing/governor-postgresql-transaction-id/pull/26


chore: updated janus-idp namespace to backstage-community, for the redhat-argocd plugin

Hey, I just made a Pull Request!
chore: updated janus-idp namespace to backstage-community
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[x] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Replacement for https://github.com/backstage/community-plugins/pull/1058

Followup in https://github.com/backstage/community-plugins/pull/1109


fix(core): check-module-boundaries logging msg should not log undefined

Currently, the console log message will show Checking module boundaries for undefined in particular branches of the function.
This just uses the nxProject variable to log the console message which seems more appropriate.

I believe I fixed the linting requirements on the PR name, but I'm not sure how to re-kick off the pr checks.

The commitlint runs on the commit message, it needs to be amended to meet requirements.


Opening hours are not ordered by weekday, when no Data is given for a day

The companyOpeningHoursList templatetag just "appends" the days where no openinghours are defined.
So when a company is closed on monday and saturday is will render the days tuesday to friday and sunday and append monday and saturday after saturday, which is confusing for the customers.
Example:
Tuesday: 9 - 5
Wednesday: 9 - 5
Thursday: 9 - 5
Friday: 9 - 5
Sunday: 9 - 5
Monday: closed
Sunday: closed

I expected the following output:
Monday: closed
Tuesday: 9 - 5
Wednesday: 9 - 5
Thursday: 9 - 5
Friday: 9 - 5
Sunday: 9 - 5
Sunday: closed

Fixed here.
Feel free to comment on other fixes and features in my fork, but please open a separate ticket so I can get it ready for a PR and merge.

@fmalina would you mind open a PR for this issue.


[SPARK-39453][SQL][TESTS][FOLLOWUP] Let RAND in filter is more meaningful.

What changes were proposed in this pull request?
https://github.com/apache/spark/pull/36830 makes DS V2 supports push down misc non-aggregate functions(non ANSI).
But he Rand in test case looks no meaningful.
Why are the changes needed?
Let Rand in filter is more meaningful.
Does this PR introduce any user-facing change?
'No'.
Just update test case.
How was this patch tested?
Just update test case.

ping @huaxingao cc @cloud-fan

ping @cloud-fan

thanks, merging to master!

@cloud-fan Thank you !


16 Bit TIFF Not being displayed

Hi, I am trying to use the .js file for a .tiff file that I have whose properties are same as the .tiff file() you used for the demo on the website(https://eox.at/2016/02/visualizing-raster-data/) but I get an error saying that
. If you could help me resolve this, that would be great. Thanks.

Hm, I can't follow.. For me, it works both on eox.at and with the current version on unpkg. Can you please clarify what version you are using and how you are using the API?


Update purge_data test to cover RemoteTroubleshootingInfo objects

Quick r?

looks good and passes. r+

Thank you!
58fcfcf Update purge_data test to cover RemoteTroubleshootingInfo objects


One of tests fails (not ok 275 - tcp_connect_timeout) on Ubuntu 20.04

Version:
libuv-v1.38.1

Platform:

$ uname -a
Linux box 5.4.0-40-generic #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

After building libuv as a local user and running make check one of the tests failed. Here is (cut) output with error messages:
$ make check
make  test/run-tests
...
not ok 275 - tcp_connect_timeout
# exit code 134
# Output from process `tcp_connect_timeout`:
# Assertion failed in test/test-tcp-connect-timeout.c on line 42: status == UV_ECANCELED
...
FAIL: test/run-tests
======================================================
1 of 1 test failed
Please report to https://github.com/libuv/libuv/issues
======================================================
make[1]: *** [Makefile:5353: check-TESTS] Error 1
make[1]: Leaving directory '/home/***/libuv-v1.38.1'
make: *** [Makefile:5613: check-am] Error 2

Please let me know if I need to send more info.

That test connects to <IP_ADDRESS>:9999, an address that's normally unreachable and times out after a while. However, if you have something in your network topology (firewall, router, etc.) that cuts the TCP handshake short, the test fails.
You can check with nc <IP_ADDRESS> 9999 - it should time out but only after several minutes have passed.

Hi, after testing few times network connectivity with nc, I can confirm that this test sometimes timeout and sometimes succeed:
$ time nc -v <IP_ADDRESS> 9998
Connection to <IP_ADDRESS> 9998 port [tcp/*] succeeded!

real	0m3,076s
user	0m0,003s
sys	0m0,000s
...
$ time nc -v <IP_ADDRESS> 9999
nc: connect to <IP_ADDRESS> port 9999 (tcp) failed: Connection timed out

real	2m10,335s
user	0m0,003s
sys	0m0,000s

When I run make check for the third time, all tests passed (after that they were mostly but not always failing).
I am not sure why would a connection to port 9999 on Google DNS sometimes succeed but it is obviously something specific with my environment.
I will close this since it seems it is something specific to my local network environment, thanks.


About the performance results

The PSNR results reported in README are even worse than MipNeRF-360. What are the possible reasons for this?
Will it produce better results if all-resolution images are used to train the model? In the original ZipNeRF paper, images in all resolutions (1x/2x/4x/8x) are used to train the model.

@xy-guo ZipNeRF also shows its single-scale results in Table3, which is about ~1dB better than mine in PSNR.

I find myself misunderstand the scale factor used in ZipNeRF paper. Their single-scale results(Table1,Table3) are conducted with factor 4 (downsample rate) for outdoor scene, and factor 2 for indoor scene, and their multi-scale results(Table2) might regard e.g.(outdoor scene)"factor 4" as full resolution which means they use factor 4,8,16,32 to train and evaluate.


Error on build

CMake Error at CMakeLists.txt:58 (string):
string sub-command REGEX, mode MATCH needs at least 5 arguments total to
command.
CMake Error at CMakeLists.txt:66 (message):
'hcc' or 'hipcc' compiler required to compile for ROCm platform.

If you are not using install script, you need to specify a HIP compiler to use cmake (e.g. CXX=hcc cmake ..). Please see README.md for details.

Yes, I assigned the hcc compiler as shown in README.md, I used the following command
CXX=/opt/rocm/bin/hcc cmake -DBUILD_CLIENTS_TESTS=OFF -DBUILD_SHARED_LIBS=ON -DBUILD_CLIENTS_SAMPLES=ON -DBUILD_CLIENTS_BENCHMARKS=OFF -DBUILD_VERBOSE=OFF
and I received the above error.
But, if I use the same command inside the build/release, I have different error as follows,
CMake Warning:
No source or binary directory provided.  Both will be assumed to be the
same as the current working directory, but note that this warning will
become a fatal error in future CMake releases.
CMake Error: The source directory "../rocSPARSE/build/release" does not appear to contain CMakeLists.txt.

You need to give cmake the relative path to CMakeLists.txt file. If you want to build from rocSPARSE/build/release, the relative path to CMakeLists.txt would be ../..

Then I got the error as previous,
CMake Error at CMakeLists.txt:58 (string):
string sub-command REGEX, mode MATCH needs at least 5 arguments total to
command.
CMake Error at CMakeLists.txt:66 (message):
'hcc' or 'hipcc' compiler required to compile for ROCm platform.
-- Configuring incomplete, errors occurred!

Did you clear your build directory before running cmake command?

Yes, nothing inside. I freshly created the directories build/release.

Can you paste the cmake output when running it on a clear build directory? What OS and cmake version are you using?

I am using cmake/3.15.2, linux OS (on summit) - nothing build in the directory


output to multicast or pipe and then gumd

After checking output parameters I only see file as output...
Is multicast / pipe / pipe+gumd supported?

Hey man I am just seeing this,
hmmm..... I just need to print to stderr , and add writing to stdout and then it will work.
Ill try to get to it today.
Good idea by the way.

now it will work
I set the default input to stdin
default out to stdout
and print everything to stderr.
input  is 0
output is 1
printing to 2

Let me know how it works out for you.


Loader have React depreceted warnings

React.createClass is deprecated and will be removed in version 16. Use plain JavaScript classes instead. If you're not yet ready to migrate, create-react-class is available on npm as a drop-in replacement.
ReactBlog
I think we must fix it, or loader will not work with React 16.0
https://github.com/jhamlet/svg-react-loader/blob/master/utility/template.txt#L4

When will this bug be fixed?

When owner merge #67 i mean. In my project i use fork

Ergh, with no changelog and no merged PRs, it's pretty difficult to tell what minimum version I need to upgrade to in order to avoid the deprecation warnings.


Code Quality Improvement - @Override annotation should be used on any method overriding (since Java 5) or implementing (since Java 6) another one

This pull request is focused on resolving occurrences of Sonar rule squid:S1161 - "@Override annotation should be used on any method overriding (since Java 5) or implementing (since Java 6) another one”. You can find more information about the issue here: https://dev.eclipse.org/sonar/rules/show/squid:S1161.
Please let me know if you have any questions.
Christian

Thanks a lot!


Remove dependent-destroy from relation

Now the related translations are not destroyed with the main object.

:metal:


Users should be able to configure the Github repo they wish to upload their files to

Text field with input for Github repo
Use github auth for the current user to ensure we can interact with Github
Maybe validate that the repo exists and is writable?

What kind of github authentication are we going to do first?

Basic auth with username and password.
Basic auth with personal access token (static OAuth token).
Full OAuth "web application flow".

The first two could potentially be done entirely client side. The third requires the server.
With the third, I believe every instance of our elm-blogger server will have to register as a distinct application on github. (That appears to be easy to do though.)
I use two factor authentication with github. It's not clear if both basic auth methods require also passing the OTP value. I use a personal access token with homebrew and that somehow authenticates without doing OTP.
Github OAuth

I reckon that the 1st is the easiest to get started with, but at the end of the day we probably want 3rd IMO. Open to anything though!


Leverage new rb-sys features for simplified CI and cross-platform builds

This PR updates the project to utilize the latest features of rb-sys.
Key changes

Simplify GitHub Actions workflows by using pre-built actions from oxidize-rb/actions
Enable some new platforms:

arm-linux
aarch64-linux-musl
x64-mingw-ucrt [^1]

Add smoke tests for many of the platform gems
Replace Rake::ExtensionTask with RbSys::ExtensionTask since it does the same thing as the old custom code
Upgrade rb-sys and rb-sys-build crates to version 0.9.94.

Tophat
For reference, you can see the passing CI builds here:

release -> https://github.com/ianks/tokenizers-ruby/actions/runs/8732060423
build -> https://github.com/ianks/tokenizers-ruby/actions/runs/8732060426

[^1]: 3pl fails currently because winapi-x86_64-pc-windows-gnu v0.4.0, how should I fix?

Saw your comment on https://github.com/ankane/tokenizers-ruby/pull/34#issuecomment-2062910399 so I closed this. If you change your mind, I'd be happy to re-open.


fix: ensure we have a config before checking rules

Codecov Report

Merging #51 (57f4128) into master (28b1e4b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #51   +/-   ##
=======================================
  Coverage   88.26%   88.26%
=======================================
  Files          59       59
  Lines         886      886
  Branches      165      165
=======================================
  Hits          782      782
  Misses        104      104

Continue to review full report at Codecov.

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

Codecov Report

Merging #51 (57f4128) into master (28b1e4b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #51   +/-   ##
=======================================
  Coverage   88.26%   88.26%
=======================================
  Files          59       59
  Lines         886      886
  Branches      165      165
=======================================
  Hits          782      782
  Misses        104      104

Continue to review full report at Codecov.

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


TCK: Enable replay-like and delay-error like Processor impls

This PR extends the TCK to support two features of Processor implementations:
Replay all
Some Processor implementations may replay all onNext items they received over their lifetime to the incoming Subscriber. The required_mustRequestFromUpstreamForElementsThatHaveBeenRequestedLongAgo however expected that a late Subscriber receives only the very latest onNext item and fail the test if any of the first two was observed. The enhancement allows observing (x, y, z) or (y, z) or (z).
Note that indeed this change may let Processor implementations pass which were supposed to emit only z. My opinion is that such implementation should already have unit tests verifying its emission pattern and the TCK should verify the implementation honors the RS protocol, even if it means getting 1-3 onNexts before the terminal event. If this is a problem, the change could be gated behind a IdentityProcessorVerification overridable property method, similar to the next change.
Emit all onNexts before an onError
Some Processor implementations may relay/replay all received onNexts items before they relay/replay a received onError event. This allows valid items to be processed before the sequence terminates with an error. Since this behavior may be specified explicitly on a Processor implementation, the TCK's IdentityProcessorVerification has been extended with a strictEventOrdering() method (default false) that when true, the otherwise failing required_spec104_mustCallOnErrorOnAllItsSubscribersIfItEncountersANonRecoverableError first consumes the pending item and then verifies the error state.
Since this change requires overriding a method, existing Processor implementations that eagerly call onError should still pass or fail this test as before.
ReplayProcessor
To demonstrate a Processor implementation that can exhibit both behaviors, a custom and package-private ReplayProcessor implementation has been added along with its TCK tests for non-strict and strict mode. (Note that this particular processor cancels its upstream if all downstream Subscribers have cancelled before the upstream's terminal event. This behavior is uncommon as ReactiveX style Processors keep running and relay new events to later Subscribers after the first set is gone.)
Related: https://github.com/reactive-streams/reactive-streams-dotnet/issues/30

@reactive-streams/contributors Yay or nay?

I think such non-identity processor could have separate standalone TCK class instead.


Implement statistics related functions

when upgrade to faiss 1.7.2, statistics related functions are not fully ported, need check

/assign

this functionality will be implemented in knowhere 2.0


Small changes to rucio-client dockerfile

Branch out of date @AndresTanasijczuk. Otherwise looks fine to me, thanks !

Ok, rebased.


CPU and RAM usage may increase with code additions

Describe your issue
Resource usage of Chtterino may grow with new additions. A lot of these additions may pile up to make it uncomfortable to use Chtterino. This may be due to RAM/CPU/Network usage.

I suggest adding benchmarks, that are executed on a daily basis and to display the results as graphs on a website somewhere. That way you can see performance regressions and investigate them.

Good idea. The biggest challenge I see with this is the design of representative benchmarks that actually measure performance during normal usage. Since we want to spot regressions introduced by new code additions, we would also need guidelines on how to write representative benchmarks for new features.


Analyzing Block Part Propagation Time and Its Impact on Network Throughput

As part of big block analysis, it is advantageous to ascertain the duration required for each proposal (block parts) to be disseminated across the network. This knowledge is crucial for gauging the fraction of block time allocated to the propagation of block parts and understanding how enhancements in block propagation speed could affect block time and, consequently, network throughput.
This task is intended to monitor the advancement of this analysis.

I have extracted the results, but the plots appear somewhat inconsistent and do not match my theoretical expectations. Specifically, the block heights for the block propagation speed, which are measured using round state tracing data, are off by approximately one height. Going to investigate it.
In the figure presented, the block gossip time represents the average duration from the receipt of proposal to the submission of prevote for all peers (99 peers in control-1 experiment) at each block height.

are off by approximately one height

yeah the block time is from the time in the commit (last commit) so its off by one

what does the script do for heights with multiple rounds?

are off by approximately one height

yeah the block time is from the time in the commit (last commit) so its off by one

I did not see any fix in the main branch, that's why I made this PR

what does the script do for heights with multiple rounds?

In this particular plot, it only captures the first round of a multi-round height. I have an extended version for height, round combinations.

When I shift the height manually, the results will be like below, however, if could have updated data it would be more accurate:

Sharing more results:

The ratio of the block propagation time to the block time

Based on this new plot, block propagation takes almost 60-80 percent of the block time.

per the two node followup that was just published, I think we actually have to dig a bit deeper to find the actually block gossip time. This is because the above data collection do not account for the time spent in Prepare or Process Proposal

@staheri14 , do you mind clarifying what is meant by this

ascertain the duration required for each proposal (block parts) to be disseminated across the network

is this the same thing as the network trace?

@staheri14 , do you mind clarifying what is meant by this

ascertain the duration required for each proposal (block parts) to be disseminated across the network

is this the same thing as the network trace? or is this blocked by the network trace?

Sure, this is how I calculated it:  the time between the receipt of a block proposal until the node issues a prevote for that proposal (indicating that the entire proposal has been dowloaded).


Do not parse Packt website to obtain Google sitekey

I've found a faster way to provide a solution to Google ReCaptcha on Packt website, it's described here As Google's sitekey does not change we don't need to open Packt Free Learning website, parse it to obtain sitekey and then create Anti-Captcha task, instead we could have sitekey saved somewhere and create the task without parsing website, we could even parallelize script execution to independently fetch data about Free Learning offers from API and solve ReCaptcha at the same time and than join both results in book claiming request.
To do so we would have to store the sitekey somewhere:

we could hardcode it in the repository (assuming it doesn't change at all or at least very often),
we could require the user to provide it in the config file,
we could also hardcode it, but provide a fallback path in which the Packt Free Learning site is being parsed.

I would go for the first solution, so I would assume that sitekey does not change and hardcode it in the code - we can choose another solution if the assumption is not correct. What do you think about that?

There is a proposed pull request, see #127.

I've merged the pull request.


device_tracker entities suddenly Unavailable

Problem
Since yesterday most of my device_tracker entities returned as Unavailable.
Didn't perform update or changes.
Running HAOS 2023.9.3 with TP-Link Deco v3.5.4.
Reloading the integration and restarting HAOS did not resolve the issue.
What went wrong here?
TP-Link Deco Version
v3.5.4
Router Model
Deco X60 (3 pieces) with M4R (3 pieces)
Debugging Information
Can provide if needed :)

Same here, since a few hours. Reinstall HACS and DECO integration didn't help either.

Version 3.5.43 I disabled fast roaming today on the DECO but it worked for a few hours. (Wallbox car charger cannot connect when enabled)

Ok guys... I managed to get it working again. Did some tweaks to the configuration and it back in business :)


The implemention of scale alignment

Hi, thanks for your excellent work. However, I have some question about the implemention of scale alignment.
In your paper, it is said that you only make predictions based on a single layer of AFA. But in the forward function of mmdet/models/dense_heads/fcos_reid_head_focal_sub_triqueue.py, feature of different FPN level are all used for detection and reid.
I am looking forward to your reply.

https://github.com/daodaofr/AlignPS/blob/98138c959059bc39e793a2a6dd164fba8388f19a/mmdet/models/dense_heads/fcos_reid_head_focal_sub_triqueue.py#L66
Here, only the first scale is utilized.

I got it. Thanks for your reply.


Improve microsite menu experience on mobile

The microsite currently has an (ever growing) menu. When visiting this website on a mobile browser, the menu takes up a lot of space. Also it overlaps text on the page you visit.

Feature Suggestion
If a visitor opens the website on a mobile browser, the menu should not take up a lot of space and not overlap any text of the page itself.
Possible Implementation
A possible solution would be switching the menu to a hamburger menu for mobile browsers and smaller screens.

Wondering if our plan to bump to docusaurus 2 is going to help with this, or at least change the work that's required. Maybe it makes sense to wait for those changes first, but still open to someone writing some quick CSS changes if it's not that much work.

Hey! I was giving a look around the opened issues here and I'd like to add some info about this enhancement request, a couple of months ago we were discussing improving the microsite menu on mobile, however, this would be possible only on docusaurus v2, which is still in beta. Then yes @benjdlambert, bumping to v2 would be possible by using a navbar property under the themeConfig prop. For those who want to give a look at how it works in action on Codesandbox.

#11780


Fails building in windows 10

Before it showed a similar message about gcc, which I installed, but now it's asking for ar, which I don't know where to get. Help is appreciated.
Compiling zstd-sys v2.0.1+zstd.1.5.2
error: failed to run custom build command for `zstd-sys v2.0.1+zstd.1.5.2`
...
error occurred: Failed to find tool. Is `ar` installed? (see https://github.com/alexcrichton/cc-rs#compile-time-requirements for help)

I'll admin not knowing much about rust installations on windows to be honest.
It looks like you have the GNU version (as opposed to MSVC). I guess you used something like mingw-w64 or cygwin to install that? Would either of them provide a ar or binutils package?

yeah, the problem is that in most places it is not mentioned that you should install some libraries with Visual Studio's help. For future reference, here is all the information to have a proper rust dev environment on windows.


Allow comments in the text file

Probably with '!' or '//' in the beginning of the line

Comments are implemented with '!' in the beginning of the line