Allow passing unlimited args to ^entry

Closes #82 (I hope) by catching all arguments and joining them into search_query.

Read my comments on #82

Read my comments on #82

Read my comments on #82

Read my comments on #82

@Codemonkey51 I looked at the docs and what @IreTheKID did seems good

@Codemonkey51 I looked at the docs and what @IreTheKID did seems good

@Codemonkey51 I looked at the docs and what @IreTheKID did seems good

Do you understand that mat made his own lib for commands lmao, it doesn't use normal discord.ext

@Codemonkey51 I looked at the docs and what @IreTheKID did seems good

Do you understand that mat made his own lib for commands lmao, it doesn't use normal discord.ext

lmao I guess I should just close this then

lmao I guess I should just close this then

lmao, I guess I should just close this then, I only know how to use discord.py

Lol its modded discord.py

lmao, I guess I should just close this then, I only know how to use discord.py

Lol its modded discord.py


Start at the very beginning with what exactly what "transactable" means in Microsoft lingo?

[Enter feedback here]

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

ID: 9f499c98-2693-d8e4-22cf-f3214d9f06f8
Version Independent ID: 3d2d7df1-2792-af03-9033-5a6af4ae7554
Content: Microsoft commercial marketplace transact capabilities
Content Source: articles/marketplace/marketplace-commercial-transaction-capabilities-and-considerations.md
Service: marketplace
Sub-service: partnercenter-marketplace-publisher
GitHub Login: @mingshen-ms
Microsoft Alias: mingshen

@S-Lovell - Thanks again for bringing this to our attention. Transactable just means exchange or capable of being transacted or different transactions that is sold through the market place.
At this moment, Since there is no doc update required, We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Fix post light broken sprite

About the PR
not a great solution but this triggers me so hard
Screenshots

Changelog

:cl:

fix: Broken post lights should no longer show an error

This quite literally is the second coming of christ.


Issue with ?colorPrimary not applying the correct color.

No matter what 'theme' I select the default primary color is only being used for ?colorPrimary.
The blue Title bar on the card is using the attribute:
android:background="?colorPrimary"

The default theme color:
    <color name="cyanea_primary_reference">#2196F3</color>
    <color name="cyanea_accent_reference">#FF5252</color>

The current applied theme in the screenshot is 'Cyanae'.

EDIT: If I leave that fragment and come back the correct styling applies. I suppose that means I need to reapply the styling in onResume in the fragment just to be sure?

Any updates on this?

I encountered the same problem as you, so I want to ask you if you have solved this problem？

I encountered the same problem as you, so I want to ask you if you have solved this problem？


Question Regarding PRs

Hello @dpkoch,
I was wondering if this repo is currently being maintained, so that my colleagues and I (in a research lab) could make a PR. Thanks!

Hi @peasant98, sorry for the delay.
I'm not really actively maintaining this repo anymore (probably obvious from my response time). If you did want to make a PR I'd be happy to take a look at it, depending on how big of a change it is. If you'd rather just continue working out of your own fork, then that's great too. Either way, thanks for reaching out!

Hi @peasant98, sorry for the delay.
I'm not really actively maintaining this repo anymore (probably obvious from my response time). If you did want to make a PR I'd be happy to take a look at it, depending on how big of a change it is. If you'd rather just continue working out of your own fork, then that's great too. Either way, thanks for reaching out!

Hi @dpkoch, we ended up finding a bug in our own code -- once we fixed it, everything went well.

Hi @dpkoch, we ended up finding a bug in our own code -- once we fixed it, everything went well.


Test Only: Regression Testing Refactored Checks for RATA

Test the remaining RATA checks that have been refactored

Testing Completed


octopusci-tentacles resets stage locker can cause duplicate jobs on a single stage

The scenario is the following. Lets say you have three stages setup test_a, test_b, and test_c. The current state of your octopusci install is that it is in the process of running two jobs one on test_a and one on test_b. You decide to use octopusci-tentacles to stop octopusci-tentacles so that you can update octopusci. When you run octopusci-tentacles stop it politely sends a msg to the job managers requesting that the job workers quit when the currently running jobs are finished.
The jobs are still running because they are long running jobs (45 min or so) and you have completed  the upgrade and you are ready to start octopusci up again so you run octopusci-tentacles start. However, when you do this it currently resets the stage locker making all of the stages available to the jobs. This is a problem though because you currently still have two jobs running. Therefore, you can easily get in a situation where you have multiple jobs running on one stage which should never happen.
One solution to this would be to make octopusci-tentacles start no longer reset the stage locker. I remember back in the day with the first version of octopusci that I made them reset for some reason. However, that case may no longer be necessary.
So, I think the proper solution is to disable it from auto resetting the stage locker on start and provide a octopusci-reset-stage-locker command that can be called to reset the stage locker if that issues ever arrises.

After some further thought it totally sucks from an initial setup perspective to have to run the following commands:
octopusci-reset-stage-locker yes
octopucsi-tentacles start

to get things up and running the first time. One of the goals of this application is to make installation and management of this application as trivial and simple as possible. Therefore, I think instead, octopusci-tentacles should check if the stage locker exists, if it does then do nothing. If the stage locker does not exist then it should initialize the stage locker appropriately. This handles the initial case.
The octopusci-reset-stage-locker command also needs to exist so that in the rare scenario that someone wants/needs to clear out the stage locker and initialize it based on the config they can.

The above listed commit implements the requirements of this ticket there for I am closing it.


A solution for "FIXME - is this a correct alpha color test?"

@RyanMallon
Hi,
After analyzing your code for the past few days I deducted a fix for the alpha test.
void sdl_blit(SDL_Surface *src, SDL_Rect *src_rect,
              SDL_Surface *dst, SDL_Rect *dst_rect,
              uint8_t base_color, bool flip_horiz, bool flip_vert)
{
    uint8_t *src_pixels, *dst_pixels, pixel;
    unsigned x, y, src_base, dst_base;

    dst_pixels = dst->pixels;
    src_pixels = src->pixels;

    for (y = 0; y < src_rect->h; y++) {
        src_base = ((y + src_rect->y) * src->w) + src_rect->x;
        dst_base = ((y + dst_rect->y) * dst->w) + dst_rect->x;

        if (flip_vert)
            dst_base = (((dst_rect->h - y - 1) + dst_rect->y) * dst->w) + dst_rect->x;
        else
            dst_base = ((y + dst_rect->y) * dst->w) + dst_rect->x;

        for (x = 0; x < src_rect->w; x++) {
            pixel = src_pixels[src_base + x]; //+ base_color;

            // FIXME - is this a correct alpha color test?
           // "pixel" contains the color index to the palette, each tileset only uses one row of the pallet.
           // So doing a modulo on "pixel" with 16 (the length of each row) will return 0 only when
           // the "pixel" is in the first position of the row.
            if (pixel % 16 != 0) {
                if (flip_horiz)
                    dst_pixels[dst_base + dst_rect->w - x - 1] = pixel;
                else
                    dst_pixels[dst_base + x] = pixel;
            }
        }
    }
}

I haven't look at this code in a long time. I think your proposed version is doing roughly the same thing that the current code does though. The base_color value is always a multiple of 16 (it would be better if the sdl_blit function documented and checked this), since callers do:
base_color = (flags & LV_PREAB_FLAG_COLOR_MASK) * 0x10;
I don't understand why you removed + base_color when setting the pixel value. Won't that make all blits just use colors 0-15 regardless of the base color?

As i understand base color is supposed to be the background color.
The if with modulo checks if the color of a pixel is in the first row (first row is only base colors) therefore if it's in the first row it should be transparent.
The + base_color would modify the pixels color and incorrect color get used.
You also have stated that The Lost Vikings doesn't use some flag stuff.
Anyway, it's an old game and as you said yourself, it's been a while since you looked at this project of yours.
I'm working on remaking the game for my final exam this semester. Your tool has come in handy.

Refreshed my memory a bit. The base_color is only used for Blackthorne, not The Lost Vikings. The Lost Vikings tilesets are always limited to 16 colours and so the base_color is always zero. See the "tilemap levels" section here: https://ryiron.wordpress.com/2017/05/06/old-school-blizzard-sprites-maps-and-palettes/
If you remove the + base_color from sdl_blit then tileset/levels in Blackthorne render incorrectly. It doesn't make a difference for the The Lost Vikings since the base_color is always zero.
The modulo check is the same as the current code, just written differently. The value of base_color is always a multiple of 16, and the pixel colours for tilesets are always in the 0-15 range.
Building a clone of The Lost Vikings for a school/uni assessment sounds ambitious! Good luck!

I probably wrote that FIXME comment because I wasn't sure if that the test against base_color was correct in all cases. This happens a lot when reverse engineering something, you can make assumptions that turn out to be slightly wrong, or in some cases you can find something that works by accident for some cases, but is actually entirely wrong. I think the current check is correct though, since all the tilesets and maps for both The Lost Vikings and Blackthorne can be rendered correctly.


Add model information for OnLogic MC510-50 (G5400T / 8G / 128G / TPM)

@rvs
Adding support for another model. A few questions to address:

This device is configurable, so I've added the root model and the config in the name. There's no full model output SKU I can use so I've just included the config variables with assigned values in the template filename.
The spec.sh always shows a bit smaller of a number for memory and disk...should I manually write those back up to their spec'd values? Or leave them as the script says?

Thanks!

Looks like the Apache Yetus check failed due to invalid permissions:
ERROR: Failed to write github status. Token expired or missing repo:status write?

@floucks -- yetus doesn't like the blank line at line 86 of your .json template file
models/template_l1_OnLogic-MC510-50_P-G5400T_M-8G_D-128G_TPM.json:86:0:blanks:end of line
That yetus complaint is also shown on the "Files Changed" tab of this pull request. Try removing that blank line and I bet it will pass.

Looks like we got it! Thanks @kgiori

@rvs @kgiori bumping this PR, looks like all tests have passed. Can you merge it and ask the ops team to push the template into my enterprise? Thank you.

Thanks for contributing this @floucks -- as to "The spec.sh always shows a bit smaller of a number for memory and disk...should I manually write those back up to their spec'd values? Or leave them as the script says?" -- either way is fine actually. I merged as-is.

Thanks @rvs !!! My pleasure.


Camera in Landscape mode

is it possible to set mobile_scanner camera in Landscape mode?
I don't see any option to set the Camera in Portrait/Landscape mode, the camera is always in Portrait mode
Thanks for help

Camera depend on your screen orientation no ?

Still getting the same behavior.
The reason is actually in this piece of code:

The snackbar is partially visible when isVisible=false and remove() method was not called.


Refactored UI code and added support for portrait animations and effects

Added a PortraitData script which gets and keeps track of icon, name, healthbar, flourishbar, and animator components whenever a new portrait is instantiated. This helps to clean up the UI code in CombatManager quite a bit and allows for more flexibility in editing the portrait in the future. Using the changes, the portrait layout was updated and animations and effects with the portrait can now be supported. Added a take damage animation as an example.

LGTM. Thanks Henry! 👍


WatchCreateRequest should take a temporary requestId

Hey guys, I am currently implementing a scala library for etcd3 in which I use the grpc protocol and using the reference here.
I am currently implementing the Watch contract and have a few questions and suggestions.
Am I correct in assuming that all watches and notifications I want to handle can be done through a single RPC stream call (because I have a bidirectional stream)?
If no, am I supposed to open a new connection for each watch?
If yes and I can handle multiple watches over a single stream, then am I correct that the creation of watches needs to be forced to happen one after another?
There is no way for  me to pair a response with a request because I will get a watchId as reponse, but there is no way to pair it with a request unless there is only one request pending which makes no sense for me?
If I send two request for a watch then there is no way for me to match the both responses to any request.
I would like to have a temporary watchId just for the create request so i can associate a request with a response.
Like this:
message WatchCreateRequest {
  // key is the key to register for watching.
  bytes key = 1;

  // used to associate the request with a given response after creating a watch
  string tmp_watch_id = 123;
  ...
}

and
message WatchResponse {
  ResponseHeader header = 1;
  // watch_id is the ID of the watcher that corresponds to the response.
  int64 watch_id = 2;
  // created is set to true if the response is for a create watch request.
  // The client should record the watch_id and expect to receive events for
  // the created watcher from the same stream.
  // All events sent to the created watcher will attach with the same watch_id.
  bool created = 3;
  // set when created is set to true, will contain the client provided tmp_watch_id so the client can
  // associate the response with a request. Note that the tmp_watch_id will not be saved, please
  // use watch_id from now on
  string tmp_watch_id = 123;
  ...
}

This would make much more sense to me as now we can send create requests in parallel.
Or am I completely wrong here?

Am I correct in assuming that all watches and notifications I want to handle can be done through a single RPC stream call (because I have a bidirectional stream)?

Sort of. But in Go client we give users the ability to choose. They can create multiple watchers. Each watcher establishes a stream with the etcd server. They can watch on multiple keys using one watcher.

then am I correct that the creation of watches needs to be forced to happen one after another?

If it is easier for you to handle the creation, then yes.

There is no way for me to pair a response with a request because I will get a watchId as reponse, but there is no way to pair it with a request unless there is only one request pending which makes no sense for me?

This is not 100% true. The response also has key and other metadata attached. You can use that to pair. You can disallow concurrent creation of duplicated watches on the same key or actually it does not really matter most of the time to pair which to which if the request is the same.

Thanks for the explanation and you are right, for the same key it does not matter.
However I still have issues to wrap my head around my use case:
I offer the developer to watch on a given key (or prefix, but lets stick to a single key) by giving me a function to call when a change happens.
Now there are may two threads which want to watch on different keys and have different function bodies.
If I issue both CreateWatchRequest at the same time then I expect two WatchResponse back, because etcd will acknowledge my create request by setting the created flag on both responses without giving any events.
Is that right?
If that is the case, then how can I determine which response belongs to which request?
As far as I can see (and tested) the WatchResponse will not return the key on which to watch.
So I dont know how to pair them.

If that is the case, then how can I determine which response belongs to which request?

Now you cannot. So you do not allow concurrent watch creation. It is usually not a problem, at least based on our experience for the Go implementation.
If there is a solid reasoning to support it, we can add additional metadata to the create response to help client lib to pair them up.

I dont know if my use case is a solid reason for you to implement additional metadata, I am just currently looking on how I can offer the best experience to my library users.
As Scala heavily uses Futures and Promises it would be great to also offer concurrent watch creation, otherwise I am forced to block on the creation of a watch (even only for a very short amount).
Thats why I would love to either have the key returned in the create response (which would solve all my problem on concurrent creation) or to have another way to pair up request and response (e.g. with a tmp_watch_id)
I mean I can work around this issue but I would love to see this fixed.

@heyitsanthony opinions?

While we are currently on this topic:
You created separate request object for creating and deleting, however for the response you chose to implement it in a single response with boolean flags for created and deleted.
oneof request_union {
    WatchCreateRequest create_request = 1;
    WatchCancelRequest cancel_request = 2;
  }

Wouldn't it make sense to also split that into three submessages?
oneof request_union {
    WatchCreateResponse create_response = 1;
    WatchCancelResponse cancel_response = 2;
    WatchEventResponse event_response = 3;
  }

Any opinions?
I think that when you offer the client to handle multiple watches over one stream, then you can not force the client to create watches synchronous.
Otherwise do it like with the leases, one request grants a watcher, one cancels a watcher and a stream is used to tell the client about watch updates.

@Chumper Anthony is on vacation (I will be on vacation today). Please expect some delay on this discussion. Sorry!

As Scala heavily uses Futures and Promises it would be great to also offer concurrent watch creation, otherwise I am forced to block on the creation of a watch (even only for a very short amount).

I don't understand this blocking argument. Anything providing a watcher will still need a create response to know whether the watch could be created and the request/response are still ultimately serialized on the tcp stream. The protocol doesn't preclude returning a future that's fulfilled once there's a create response; etcd's clientv3 library handles it by maintaining a queue of create requests, dequeuing and sending create requests once the pending response arrives.
The bigger problem is that registering n watches will necessarily cost n*RTT. This is a problem if there are many watches registered on a single stream, but it's unclear whether this is a common case.

Wouldn't it make sense to also split that into three submessages?

Sure, but this will break backwards compatibility. Not an option at this point.
Concurrent watch creation can probably be supported by adding a watch id field to the create request similar to the tmp_watch_id thing. If the given watch_id is 0 then etcd uses the old serializing behavior. Otherwise, etcd returns the usual create response if the watcher can be created / return a canceled response if it fails. This should buy full client control over the response tagging (instead of having to ask etcd for a watchid/tag) without introducing a lot of extra protocol details.

The bigger problem is that registering n watches will necessarily cost n*RTT. This is a problem if there are many watches registered on a single stream, but it's unclear whether this is a common case.

That is exactly the point in my question, in my library I would also need to create a queue with requests and block behind the curtain aka. create one watch after another.
For the end developer it still looks like he can create multiple watches, but in fact the client is blocking in this case on each creation.
I currently have only one watch created, so I don't have the required use case for multiple creations.
But if I just imagine, that an application on start needs to create like 10 watches then the start up time increases.

Sure, but this will break backwards compatibility. Not an option at this point.
Yes, this was just a side question, I understand your point here, even though you could add submessages while still being backwards compatible.

This should buy full client control over the response tagging (instead of having to ask etcd for a watchid/tag) without introducing a lot of extra protocol details.

Thats why i suggested a tmp_watchid.
The id etcd returns is fine as it is unique for the etcd instance.
If the client is in full control of the watch_id it is a bad thing because then the client has to come up with a reasonable good (kind of) uuid for watches.
Instead i would just let the client control the creation flow id and leave the rest for etcd which will minimize the potential conflicts of ids as the client only creates them for the request.
You don't even have to store it anywhere, just a a create_id or whatever to the request and response and let etcd return the create_id if available, then the client can match request and response and you wouldn't have to change any logic.

If the client is in full control of the watch_id it is a bad thing because then the client has to come up with a reasonable good (kind of) uuid for watches.

The watch id is 64-bit. Keep a counter per stream and increment for every create request; it'll never run out of unique id's.
I don't understand the advantage to having a separate create id instead of directly asking for a specific watch id. The client would still be responsible for choosing unique ids to avoid collisions on create_id's and it lacks the flexibility of being able to choose a watch id (e.g., a client keeps an array and wants to map the indexes watch ids).

add a create_id or whatever to the request and response and let etcd return the create_id if available

I feel that if the client is going through the trouble of sending something to the server, it'd be nicer to have etcd do more than just relaying the data back.

The watch id is 64-bit. Keep a counter per stream and increment for every create request; it'll never run out of unique id's.

So if two different streams chose the same watch_id then etcd will create two different watchers?
I thought the watch_id must be unique for all watches, but maybe I am wrong here?
Or how do I set the starting id for the watch_ids?

I don't see the advantage to having a separate create id instead of directly asking for a specific watch id. The client would still be responsible for choosing unique ids to avoid collisions on create_id's and it lacks the flexibility of being able to choose a watch id (e.g., a client keeps an array and wants to map the indexes watch ids).

Yes, but it is only responsible for choosing an id for its own creation flow. So the potential conflict zone is limited to all creation flows the client does on this same stream, here the client can just increment a counter for the temporary ids to surely match request and responses.
Maybe I have a wrong assumption here, I am assuming the watch_id MUST be unique for all watchers of the etcd cluster. If that is the case then letting the client choose the id will rise the conflict potential.
If that is not the case and watch_ids must only be unique per stream, then sure we can go ahead and just add a new field to the create request.

I feel that if the client is going through the trouble of sending something to the server, it'd be nicer to have etcd do more than just relaying the data back.

Fair enough.

So if two different streams chose the same watch_id then etcd will create two different watchers?

Yes. The watch id is a per-stream resource. Two separate streams can watch on different ranges with the same watch id.

Ok, sorry for the missunderstanding and then I do fully agree with you that adding a watch_id to the request will also solve the problem when the server uses the given id.

@Chumper Good to see you and @heyitsanthony agree on the same solution. Are you interested in working on this feature?

I would, but unfortunately I haven1t programmed in go before. I searched for the file but because I am not familiar wih go and the structure of code I did not find it. So it would love to see it implemented but I think I am unable to do so.

@Chumper Understood. No problem. Thank you!

@Chumper Thanks for bringing this issue up. I'm also implementeding v3 watch on Scala, so maybe we can get in touch and track this together. Will watch :) the issue.

@xiang90 I'd be more than happy to take this on if no one else is already doing so. @styleex just pointed out that this is a potentially buggy behavior in my Js/Ts etcd client (I assumed ordering). For now I'll likely implement a queue as Chumper mentioned earlier but I'd like to fix this at the source 😄

@connor4312 It would be great if you can work on it. Thank you!

moving this to 3.4.
@connor4312  it would be great if you still have interest in this one.

I'll take a stab at it this weekend

I've implemented this in https://github.com/coreos/etcd/pull/8662


[AST] Update internal AST logic

Signed-off-by: Jacob Levy<EMAIL_ADDRESS>

The CI (private) now fails on 45 minute timeout….
All the other checks passed!
Can the AST PR approved & merged with this non-specific iail?
Regards,
Jacob

Check failure on line 486 in Build log
@azure-pipelinesazure-pipelines
/ CI (private)
Build log #L486
The operation was canceled.

@msf
Need your help with this pr. Not sure what is wrong
Thanks

it seems like there are 2 top level tests that got stuck.
Are you able to follow our instructions and run sims directly with dvsim?
It's not clear which test got stuck, so I would try some of the top level tests.

I ca not run dvsim nor any of the test inside CI (private). That's why I asked for a waver on this check.

ah yes. I'll have to pull down your PR and have a look then.
I couldn't tell immediately which test hung.
We most likely cannot waive this, because it appears some tests have gotten
stuck.  (assuming i was looking at the right output).
 Sri made the tool
pretty generic, and the intent was that multiple partners should be able to
run it.
If you have specific difficulties, it would be great if you can file issues
on it so we can see what's going on.
On Mon, Jun 21, 2021 at 1:28 PM Jacob-Levy @.***> wrote:

I ca not run dvsim nor any of the test inside CI (private). That's why I
asked for a waver on this check.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/pull/7043#issuecomment-865322965,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSTX4QBXCGQIW6YJLRLTT6OFPANCNFSM466EUUBA
.

I have restarted private CI on Azure (sometimes these tests time out). let's see if it passes now.

Michell,
How did you restart only the CI (Private)?
I was looking for it when I noticed it timeoutt....

Hey Jacob, when you click on "Details" you will see a "re-run" link that can be clicked right next to the failed tests (still on the GitHub test summary page https://github.com/lowRISC/opentitan/pull/7043/checks?check_run_id=2879140143). When you follow "View more details on Azure Pipelines" link to the Azure dashboard, there is also a button somewhere at the top-right that allows you to "Rerun Failed Jobs".

Will wait for issue #7056 to be resolved  and reissue the PR with latest OS AST.


Email Verification Feature

Improve user authentication by email verification, and ensure the user's email is valid and active.

Successfully implemented this new feature!


chore(package): set env to prod when building for publish

Deploy preview for hopeful-hamilton-4090b9 ready!
Built with commit 16e657d0b1c282bb44c7313ebc5ed960c564e2ee
https://deploy-preview-751--hopeful-hamilton-4090b9.netlify.com


cloudflare page 部署失败

我准备把您这个部署在 cloudflare pages ，部署过程中提示

11:17:37.285 | Executing user command: jekyll build
-- | --
11:17:38.487 | /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/runtime.rb:304:in `check_for_activated_spec!': You have already activated i18n 1.14.1, but your Gemfile requires i18n 0.9.5. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)

11:17:37.285 | Executing user command: jekyll build
-- | --
11:17:38.487 | /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/runtime.rb:304:in `check_for_activated_spec!': You have already activated i18n 1.14.1, but your Gemfile requires i18n 0.9.5. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)

11:17:37.285 | Executing user command: jekyll build
-- | --
11:17:38.487 | /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/runtime.rb:304:in `check_for_activated_spec!': You have already activated i18n 1.14.1, but your Gemfile requires i18n 0.9.5. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)

我把 build command 调成 bundle install; bundle exec jekyll build，但是出现这样的错误了：
23:29:23.833 | <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require': cannot load such file -- rexml/parsers/baseparser (LoadError)
23:29:23.833 | from <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
23:29:23.833 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/kramdown-1.17.0/lib/kramdown/parser/html.rb:10:in `<top (required)>'
23:29:23.833 | from <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
23:29:23.834 | from <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
23:29:23.834 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/kramdown-1.17.0/lib/kramdown/parser/kramdown/html.rb:10:in `<top (required)>'
23:29:23.834 | from <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
23:29:23.834 | from <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
23:29:23.834 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/kramdown-1.17.0/lib/kramdown/parser/kramdown/paragraph.rb:14:in `<top (required)>'
23:29:23.834 | from <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
23:29:23.834 | from <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
23:29:23.834 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/kramdown-1.17.0/lib/kramdown/parser/kramdown.rb:345:in `<class:Kramdown>'
23:29:23.834 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/kramdown-1.17.0/lib/kramdown/parser/kramdown.rb:60:in `<module:Parser>'
23:29:23.834 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/kramdown-1.17.0/lib/kramdown/parser/kramdown.rb:19:in `<module:Kramdown>'
23:29:23.835 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/kramdown-1.17.0/lib/kramdown/parser/kramdown.rb:17:in `<top (required)>'
23:29:23.835 | from <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
23:29:23.835 | from <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
23:29:23.835 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/jekyll-3.8.5/lib/jekyll/converters/smartypants.rb:3:in `<top (required)>'
23:29:23.835 | from <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
23:29:23.835 | from <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
23:29:23.835 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/jekyll-3.8.5/lib/jekyll.rb:13:in `block in require_all'
23:29:23.835 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/jekyll-3.8.5/lib/jekyll.rb:12:in `each'
23:29:23.835 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/jekyll-3.8.5/lib/jekyll.rb:12:in `require_all'
23:29:23.835 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/jekyll-3.8.5/lib/jekyll.rb:194:in `<top (required)>'
23:29:23.835 | from <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
23:29:23.835 | from <internal:/opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
23:29:23.835 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/jekyll-3.8.5/exe/jekyll:8:in `<top (required)>'
23:29:23.836 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/bin/jekyll:25:in `load'
23:29:23.836 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/bin/jekyll:25:in `<top (required)>'
23:29:23.836 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/cli/exec.rb:58:in `load'
23:29:23.836 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/cli/exec.rb:58:in `kernel_load'
23:29:23.836 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/cli/exec.rb:23:in `run'
23:29:23.836 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/cli.rb:492:in `exec'
23:29:23.836 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
23:29:23.836 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
23:29:23.836 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
23:29:23.836 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/cli.rb:34:in `dispatch'
23:29:23.836 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
23:29:23.837 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/cli.rb:28:in `start'
23:29:23.837 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.4.10/libexec/bundle:45:in `block in <top (required)>'
23:29:23.837 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/bundler/friendly_errors.rb:117:in `with_friendly_errors'
23:29:23.837 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.4.10/libexec/bundle:33:in `<top (required)>'
23:29:23.839 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/bin/bundle:25:in `load'
23:29:23.840 | from /opt/buildhome/.asdf/installs/ruby/3.2.2/bin/bundle:25:in `<main>'
23:29:23.842 | Failed: Error while executing user command. Exited with error code: 1
23:29:23.851 | Failed: build command exited with code: 1
23:29:24.784 | Failed: error occurred while running build command


[fix] sitemap addon body load_sitemap_urls

Coverage decreased (-1.5%) to 83.379% when pulling 2efc7aa5393a78445c1fa9c043c8453734759afd on fix-load-sitemap-urls into 706701cd79ab07daadd6570099ce5b07f63206a2 on master.


Add link to blog post about function bind syntax

I was having a difficult time figuring out what features some plugins add. I think a "Learn more" section with either a code example or a link would be helpful so people can read more about the feature. Would it be okay if I start adding this section to a few of the plugin's documentation that I know about?

Would it be okay if I start adding this section to a few of the plugin's documentation that I know about?

Sure! Could you just make the changes I commented above and do that everywhere?
It'd also be good to link stuff like MDN/spec/proposals wherever possible

Thanks for the comments. I've updated this page. I'll add similar links and headings to the other plugins that I understand. Would you prefer one PR with several changes or one PR for every page updated?

Putting it in this one sounds fine to me

Sounds good. I'll update this PR over the next couple of days. I'll leave a note when I think it's ready for another review. Thanks!

@spadin You can probably just use the links from https://github.com/tc39/ecma262#current-proposals or maybe link to that too

Sweet. Thanks for the link. I'll use those links wherever I can.

If you like these change, could we merge it? Then I can take some time this weekend to look for other pages I can update. Just so we don't leave this PR open for too long.


[$250] Android - Room - When 2nd user suggestions whisper triggered, 1st whisper disappeared

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

Version Number: 9.0.19
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team
Action Performed:

Launch app
Tap on a room chat
Enter<EMAIL_ADDRESS>& send the message
Note whisper is shown
Enter<EMAIL_ADDRESS>& send the message
Note whisper for step 5 user shown but step 4 whisper disappeared.
Navigate to troubleshoot-- clear cache
Revisit the room chat
Now note 2 whisper message displayed

Expected Result:
When 2nd user suggestions whisper triggered, 1st whisper must not be disappeared
Actual Result:
When 2nd user suggestions whisper triggered, 1st whisper disappeared
Workaround:
Unknown
Platforms:

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

[ ] Android: Native
[x] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/user-attachments/assets/6496f93c-4c6e-4472-a32d-7462cd02da97
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01510cc10b7d91bb22
Upwork Job ID:<PHONE_NUMBER>599453123
Last Price Increase: 2024-08-20

Issue OwnerCurrent Issue Owner: @akinwale

@sonialiap  FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

Sounds like a bug to me

@stephanieelliott I'm OOO Aug 19-30, adding leave buddy.
Status: waiting for proposals

Still waiting for proposals.

Hi, I’m Bartek from Callstack and I would like to work on this issue.

Proposal
Please re-state the problem that we are trying to solve in this issue.
After mentioning a user who are not in the cureent room the second time, previous ACTIONABLEMENTIONWHISPER message disappear.
What is the root cause of that problem?
Short Answer
After mentioning a user who is not in the current room the second time, the browser requests the addComment api to the backend, then the backend gives back an inappropriate response that contains a merge command that will delete the previous ACTIONABLEMENTIONWHISPER message.
Long Answer
Let's observe three JSON segments first.
Onyx data after update from the previous response(Unrelevant fields are omitted):
{
    "reportActions_3703223916129889": {
        "297903893454568668": {
            "actionName": "ACTIONABLEMENTIONWHISPER",
            "message": [
                {
                    "deleted": "",
                    "html": "Heads up, <mention-user accountID=15075387></mention-user> isn't a member of this room.",
                    "isDeletedParentAction": false,
                    "isEdited": false,
                    "text": "Heads up,  isn't a member of this room.",
                    "type": "COMMENT",
                    "whisperedTo": [
                        17159591
                    ]
                }
            ],
        }
    }
}

Onyx data after update from the previous response(Unrelevant fields are omitted):
{
    "reportActions_3703223916129889": {
        "297903893454568668": {
            "actionName": "ACTIONABLEMENTIONWHISPER",
            "message": [
                {
                    "deleted": "2024-08-23 17:15:21.188",
                    "type": "TEXT"
                }
            ],
        }
    }
}

Onyx data after clearing cache and refresh(Unrelevant fields are omitted):
{
    "reportActions_3703223916129889": {
        "297903893454568668": {
            "message": [
                {
                    "type": "COMMENT",
                    "html": "Heads up, <mention-user accountID=15075387></mention-user> isn't a member of this room.",
                    "text": "Heads up,  isn't a member of this room.",
                    "isEdited": false,
                    "whisperedTo": [
                        17159591
                    ],
                    "isDeletedParentAction": false,
                    "deleted": ""
                }
            ],
            "actionName": "ACTIONABLEMENTIONWHISPER"
        }
    }
}

We can see in Onyx data after updating from the previous response, reportActions_3703223916129889.297903893454568668.message.deleted is modified to a specific timestamp from an empty string and reportActions_3703223916129889.297903893454568668.message lost detail message to show in the UI layer. After my investigation, I got that ReportActionsUtils.isDeletedAction(reportAction) equals false when deleted is set to an empty string and ReportActionsUtils.isDeletedAction(reportAction) equals true when deleted is set to a specific time stamp. That ReportActionsUtils.isDeletedAction(reportAction) equals false will result in this report action not showing in the UI layer.
What makes the modification? It's the second response of the addComment api.
Let's compare the first and the second response of the addComment api. The difference is here. We can see onyxData[0] makes the modification.
So the root cause is the inappropriate response of addComment api from the backend.
What changes do you think we should make in order to solve the problem?
Ask the backend developer to remove the logic that generates onyxData[0] in  the second response of the addComment api.
What alternative solutions did you explore? (Optional)
none

Sounds good @burczu, will assign you!

@akinwale Please take a look at the proposal from @VincentCorleone - I've requested to be assigned to this issue as a contributor from the agency, but if the proposal is legit, I think it's better to assign its author.

Hey @akinwale bump on the above ^^, can you review the proposal for us?

After taking a look, the proposal suggests that this ideally should be fixed in the BE. The alternative approach is more of a workaround which isn't suitable, so we're looking for a better solution on the frontend, if viable.
cc @stephanieelliott @burczu

@akinwale I've done my research and I agree with the @VincentCorleone proposal, that this is the backend issue and we should ask someone from the backend team to take a look at this.
This part of the AddComment API response removes the previous whisper indeed:

Sounds like both @akinwale and @burczu agree that this should be an internal issue 👍 ? If yes, I'll add the internal label

Sounds like both @akinwale and @burczu agree that this should be an internal issue 👍 ? If yes, I'll add the internal label

Yes, this can be made internal.

Moved to internal

VSB is on hold so internal issues aren't being picked up unless it's an important bug. I don't think this issue is critical but would be good to fix, so keeping it open but moving to weekly

Not an engineering priority

closing for focus


Make jquery in commonjs a standard dependency

Context
Looks like this all started back in #2862, which added a UMD wrapper in which jquery was omitted as a dependency when a commonjs environment was detected, based on the reasoning that commonjs is for the server side and jquery is not needed on the server side. In this first iteration of the UMD, Backbone.$ was left undefined in the commonjs environment. However, commonjs was becoming increasingly common on the client side thanks to tools like browserify, Web Pack, component, cartero, et. al. #2862 was then merged so that backbone could be used with jquery in commonjs environments, which added a require( 'jquery' ) but wrapped it in a try / catch. However, this "light dependency" approach "broke" browserify, as discussed in #2997, since browserify would fail if jquery was not present. As a result of this issue the require + try / catch was removed altogether, and it was made a requirement to explicitly set Backbone.$ in all commonjs environments.
var Backbone = require('backbone');
Backbone.$ = require('jquery');

Unfortunately, we've seen this solution also has its share of problems:

the requirement of setting Backbone.$ = require('jquery') is not intuitive and most people miss it, which is a constant source of friction (see #3038 and #3240).
that pattern can not be used in Firefox plugins (see #3156).
there are issues when a third party module requires jquery to be set on Backbone.$ (see #3291). Under the current paradigm, eventhough the module needs jquery to be available at Backbone.$, potentially even at load time, the responsibly for putting it there falls on the application developer, not the module author. The module author has no way of guaranteeing what the application developer is going to put there when, and the application developer is burdened by what is really an internal concern of the module.

Proposed solution
The proposed solution in this PR is to go with the straight forward solution of treating jquery as a standard dependency (as it is in AMD environments). What follows is a break down of how this solution would play out with the various use cases.
On the server side (node)
For people using jquery
Everything just works.
For people who do not need a DOM library
jquery will install and will load when the node application starts up, as soon as backbone is required, eventhough it is not needed. However both the disk space it consumes and the time it takes to load are too small to have any consequential impact.
For people who want to use a DOM library other than jquery
Same as above case, except that Backbone.$ will need to be set to the alternate DOM library during startup. (Assuming node_modules has been deduped, the backbone module is shared accross the entire application and thus setting Backbone.$ at application startup is sufficient to ensure that the alternate DOM library is always used by backbone.)
On the client side
For people using jquery
This is the most common case, I think. Using this approach, everything just works for this case as expected. (Note that npm dedupe still needs to be run to make sure that only one copy of jquery will be floating around.)
For people who want to use a DOM library other than jquery
This is the group of people who would be inconvenienced by this approach. Luckily the inconvenience is pretty minimal. They need to either
a) Explicitly set Backbone.$ to the DOM library of their choice whenever a page is loaded, and then configure the build tool to ignore the jquery dependency (so that jquery is not dead weight in their js bundle). With browserify, the exclude option can be used to have require('jquery') return undefined:
browserify main.js --exclude jquery > bundle.js

With Web Pack,
{
    plugins: [
        new webpack.IgnorePlugin(/^jquery$/)
    ]
}

b) configure their build tool to "alias" jquery for another library. With browserify, this can be done with aliasify,
npm install --save aliasify

Add an "aliasify" section to the application's package.json:
{
    "aliasify": {
        aliases: {
            "jquery": "zepto"
        }
    }
}

Using WebPack, the resolve.alias configuration option can be used:
{
    context: __dirname + "/app",
    entry: "./entry",
    output: {
        path: __dirname + "/dist",
        filename: "bundle.js"
    }
    resolve : {
    	alias : {
			"jquery": "zepto"
		}
	}
}

For people who want to use a DOM library with backbone and jquery in other places
Just set Backbone.$ explicitly to the library of their choosing.
Comparison with try / catch
Another solution worth considering is to go back to #2862 which wraps the require( 'jquery' ) in a try / catch. This solution would also address most of the problems with the current approach. However,

I don't see a significant upside over the standard dependency approach.
#2997 would again be a problem, which we know for sure, since we have been there before.
The lack of clarity as to what is actually supposed to be at Backbone.$ presents a problem for module and meta framework authors. I agree with @akre54's comment:

Marionette should be using the same jQuery as Backbone and the same jQuery as your app. It becomes an absolute mess when your view's $el property has a different $.fn than the rest of your app

But where is the global jquery object? External modules and meta frameworks can not assume Backbone.$ is jquery and interact with it as such if there is no firm stance taken. What is Backbone.$ supposed to be in the baseline case? Is it jquery? Is it zepto?
If backbone has a standard dependency on jquery then it is clear - the baseline case is that Backbone.$ === the global jquery object.

@dgbeck Want to amend your PR to include the proper version range?

I'd say version range should be *. How about using a second file browser.js which sets Backbone.$ for you, this way loading jquery won't be necessary on node

Well, not every jQuery supports exports. As far as I can tell it was only added in 1.10.0/2.0.0.

this way loading jquery won't be necessary on node

Is it that big of an issue to load jQuery in Node? Perhaps it's slightly wasteful, but otherwise it should be harmless and side-effect-free.

See https://github.com/jashkenas/backbone/pull/3421#issuecomment-67872505. I think the original try-catch was the perfect solution, we just need to document how to exclude jQuery when it's unneeded or how to alias/remap it to another dependency when something else is needed.

But server side doesn't really have code-size issues the way client-side does. Who cares if you load jQuery on the server when you don't use it?

Who cares if you load jQuery on the server when you don't use it?

No argument against it.

It's an extra two megabytes in every npm-installed copy of Underscore.
Given that even dev Backbone is just a 60k script — that's a little bit nasty.

I agree with @jashkenas, we don't need to make jQuery a hard npm dependency but importing with try { } catch() {} should still work if the user sets $ as a dependency in their project (parent node_module folder) right?

Yep, people just have to manually include the two megabytes now.
The volume of people that are confused by this, and the "anti-pattern" that backbone uses as far as the jquery dependency goes is really unfortunate.
I get it though, developers should be good at debugging so they should just figure it out, and figure out what flavor of shim they need to get around this design decision.

Sorry, just saw the recent activity here this afternoon.
It looks like the first version of jquery available on npm was 1.5.1, and that version supports exports. However I think using "*" as @megawac suggested makes more sense. (I could not find a minimum required version of jquery in the backbone docs.) This PR has been updated with a wildcard dependency, but I'm happy to change it to whatever is requested.
In terms of to try / catch or not to try / catch, either way is a step up from where we are now.
But to play with some numbers, if we were to go with the try / catch approach, say around half of all people using commonjs on the client side would have to spend some time debugging why their build system is failing with an out of the box version of backbone -- all those people that install backbone and try to compile their assets without installing jquery will run into this problem.
On the other hand, if we go with the standard dependency approach, I will venture to say that at worst 5% of people who are in the (smaller) group of server-side devs using backbone would be annoyed that there is a jquery dep that is not being used, and they would get over it quickly, without having to invest any time in debugging anything. Yes, 2 megs is big relative to backbone, but it is not a significant portion of a modern web application.
In the interest of a thorough exploration, there is an additional con to the standard dependency approach worth reiterating, although it falls more in npm's court to resolve than it does in backbone's. If jquery is a standard dependency of backbone, and backbone is installed first, and then jquery is installed on the app level later, there will be two copies of jquery, unless npm dedupe is run. For instance
npm install --save backbone
npm install --save jquery

Now we have
app
   backbone
      jquery
      underscore
   jquery

This is an unfortunate situation. As already discussed in this thread, having multiple copies of jquery floating around is likely to cause problems. Plugins installed on one jquery instance are not available on another, data attached to DOM nodes using the $.data method of one jquery instance is not accessible when using the other instance, etc. npm dedupe solves the issue, but not everybody runs that command. The good news is that npm 3, very quickly approaching release, is going to fix this issue, running a dedupe on every npm install.
All in all, the standard dependency approach seems like the more solid long term solution.

Thinking this through again, I don't think we should change this at the moment. Perhaps at a future date. Why?
* Despite the rise of alterna-npm client-side loaders, npm is still first and foremost Node's package manager.
* "Real" JavaScript modules in ES20Whatever won't be "CommonJS", they'll be something else.
* `Backbone.$ = require('jquery')` really isn't very much to ask.
* "How do I stop Backbone from loading jQuery when I don't want it?" Would be much harder to answer.

:expressionless:

Despite the rise of alterna-npm client-side loaders, npm is still first and foremost Node's package manager.

Agreed. But people are using it for client-side now. And it will get better in npm land.

"Real" JavaScript modules in ES20Whatever won't be "CommonJS", they'll be something else.

CommonJS is here, and people are using it and have been using it for years. imports is a syntax addition that will require Backbone to be transpiled to be used anywhere else. We can always add System or whatever support when that actually lands.

Backbone.$ = require('jquery') really isn't very much to ask.

Yes it is. It's non-obvious, and breaks in CommonJS environments where you can't modify modules (#3156.).

"How do I stop Backbone from loading jQuery when I don't want it?" Would be much harder to answer.

When would this happen? So long as we don't add the dependency to Backbone's package.json we should be fine. If you need it, you add it to your app's package.json. If you don't, don't. It just works.
I appreciate you taking a decisive stance on this, I just happen to think it's the wrong one.

:|

Oh, I'm sorry — I was looking at this pull request, which does add jquery to package.json.
If we're not going to do that, then this PR needs to be changed.

Thanks for reevaluating.
Ok so game plan: @dgbeck remove jquery dependency from package.json and wrap the jQuery require in a try...catch. Right?

Doesn't the try/catch break many of the commonjs tools that brokenly try to statically analyze your script for require statements?

As far as I'm aware that's mostly with browserify. You tell it to ignore or exclude jquery and it works fine. https://github.com/jashkenas/backbone/issues/2997#issuecomment-67675558

I think the try-catch is the correct solution as well. https://github.com/jashkenas/backbone/pull/3421#issuecomment-67872505

Okay then. Let's either amend this pull request, or close it in favor of an agreed-upon one.

To get the ball rolling: #3542.


Improve read-only editor access

Adds a "freeze" function to the database view.
Adjusts CSS to make read-only mode more readable; fixes #417
Automatically enters read-only mode for reviewing submissions

FYI updated background color; I went with #ebebe4, which has a bit of yellow in it...

I don't think you meant to add this styling in reaction.css. The background color for the edittext CSS styling should be white (or undefined). I think this is a good color choice for a $('.edittext').css('background-coior', '#ebebe4'); in ord.reaction.freeze

haha fixed :)


OSError: /opt/models/retinaface/libplugin_rface.so: cannot open shared object file: No such file or directory

Am trying this repo, but facing issue in line 24 in src/kbds/app/face.py
How to solve it?

@shaluashraf this line loads decoder file for model file generated by tensorrtx. If you follow every steps in tensorrtx repo, you should find a file named "libdecodeplugin.so". that's the one you should load before init the model.


Webpack/React externals dependency

Fixes DSD-360
This PR does the following:

Allows React hooks to work by installing one version of react and react-dom in the consuming application.

Add a combination to webpack.config.js and package.json  that allows apps to import components that use React hooks. @bigfishdesign13 can you try this in a consuming application before it's merged? So far it works but it might mean that react apps need to use the same react version which is 16.14.0. I'm trying to see if there's a way to make 16.13.0 a minimum and resolve to 16.14.0 for the app.

Tested with "@nypl/design-system-react-components": "git+https://github.com/NYPL/nypl-design-system#DSD-152-externals", in package.json.

Front End Review:

[ ] View the example in Storybook

Okay, the last commit works! I tried it in both the LCA and DRB:

Some updates and why the latest one works:

We have to not bundle react through webpack so we have to tell it not to -- that's in the webpack.config.js file.
We have to set up peerDependencies and get a minimum. I choose to go with >=16.13.0 since most apps should use at least that React version (but it is kind of arbitrary).
Before, react was a dependency but it should be a devDependency.

I a previous commit, the package worked in DRB since it uses react 16.14.0 but LCA broke because it was using 16.13.1. So I configured it so it gets the minimum working version to use. If you run npm ls react or npm ls react-dom, you'll see the hierarchy tree of dependencies and the exact version it installs. If it installs more than one version, that's where the problem happens. With the last commit, running the command npm ls react in LCA gets me version 16.13.1 and in DRB it is version 16.14.0.
So it is working as expected -- it is taking the minimum version from the application and from the DS to use so there is no confusion.
This leads to: we haven't set a "this is the minimum working version of react your app needs to use DS". I think now is an appropriate time to say that we want to go with at least a version of 16.13.0. This can be updated since the minimum to use react hooks in 16.8.0... but at this time point I think apps should use a higher version.
@wluisi What version is the Location finder using and would this approach work?

@EdwinGuzman I think it should be fine. Currently Location Finder is on React 16.13.1.


webhook not triggering

Hi! first of all: thanks for your nice work! :- )
I don't get the web hook running for batteryLevel.
I did configure the webhook ID, but the script seems not to trigger or send data to this webhook.
I do get a update in the protocol:
New battery level: 100 for page 1
and as a sidenote: the AddOn does not show itself as running in HA, but keeps the "red" flag on the top right and the script asks for "Start"

I've noticed that it crashes sometimes at startup. Check the Logs tab and you may need to refresh the AddOn page to see if it's actually still running.

no, it is not on the list, but I checked "Only accessible from the local network" because it does not need to be exposed.
I can manually trigger the webhook and it does work. The AddOn just does not!?

Hey all,
I'm personally not using the HA addon so I may only be able to give you some technical insights.
What's internally done: the URL is built in the way that {HA_BASE_URL}/api/webhook/{HA_BATTERY_WEBHOOK} is used as the URL. A POST request with { batteryLevel: 50, isCharging: false } is sent there.
I'll try to add some logging to the addon in the next version to investigate this further, but maybe you can manually trigger this via curl or so and do some further testing meanwhile?

Hi!
got it working. First: the option for "Only accessible from the local network" must NOT be checked in order for it to work (not sure why) and the second thing is: the web hook gets triggered not on the picture download to the kindle, but on the next PNG-update from the AddOn.
So for the moment everything works fine. Thanks again for your help and efforts! :- )


NSwag contracts

Maybe it's there and I couldn't find it, but when generating contracts, I'd like to specify some NSwag options like dateType (I don't like DateTimeOffset) or arrayType.

Yeah, there's a lot of default parameters in CSharpClientGeneratorFactory.

@bielik01 I actually have this in my backlog. I plan to expose settings to customize the entire CSharpGeneratorSettings
You have things like these options that can be customized
AnyType = "object";
Namespace = "MyNamespace";

DateType = "System.DateTimeOffset";
DateTimeType = "System.DateTimeOffset";
TimeType = "System.TimeSpan";
TimeSpanType = "System.TimeSpan";

ArrayType = "System.Collections.Generic.ICollection";
ArrayInstanceType = "System.Collections.ObjectModel.Collection";
ArrayBaseType = "System.Collections.ObjectModel.Collection";

DictionaryType = "System.Collections.Generic.IDictionary";
DictionaryInstanceType = "System.Collections.Generic.Dictionary";
DictionaryBaseType = "System.Collections.Generic.Dictionary";

ClassStyle = CSharpClassStyle.Poco;
JsonLibrary = CSharpJsonLibrary.NewtonsoftJson;

RequiredPropertiesMustBeDefined = true;
GenerateDataAnnotations = true;
TypeAccessModifier = "public";
PropertySetterAccessModifier = string.Empty;
GenerateJsonMethods = false;
EnforceFlagEnums = false;

InlineNamedArrays = false;
InlineNamedDictionaries = false;
InlineNamedTuples = true;

So the .refitter settings file might look something like:
{
  "openApiPath": "./OpenAPI/v3.0/petstore.json",
  "namespace": "Petstore",
  "contractsGeneratorSettings": {
    "dateType": "System.DateTime",
    "dateTimeType": "System.DateTime",
    "arrayType": "System.Collections.Generic.IList"
  }
}

@all-contributors please add @bielik01 for ideas

Is it "contractsGeneratorSettings" or "codeGeneratorSettings"? In the README it's the former and neither of them works..

Also I just confused with "namespace" being mentioned at the top level AND the settings part. The former is valid.

Oh wait, I guess this is not yet reached nuget..

Is it "contractsGeneratorSettings" or "codeGeneratorSettings"? In the README it's the latter.
Also I just confused with "namespace" being mentioned at the top level AND the settings part. The former is valid.

I went with codeGeneratorSettings as it's not only the types used in the contract/dto, it's also the arguments and return types in the Refit interface

Also I just confused with "namespace" being mentioned at the top level AND the settings part. The former is valid.

This is a mistake and only the top level namespace is used. The codeGeneratorSettings was a copy of the NSwag type, and I was supposed to clean it up
Thanks for pointing that out @alrz

@all-contributors please add @alrz for bugs

but that was namespace for contracts, it was perfectly fine there

but that was namespace for contracts, it was perfectly fine there

@bielik01 Are you interested in having different namespaces for contracts and the interfaces? That's not how its currently implemented and I originally wanted to use the same namespace for all generated types, be it DTO objects or the interface(s), since they are in the same file. Having different namespaces for contracts and interfaces would require importing the contracts namespace into each interface, or specifying the full type name on all usages
I have toyed with the idea of splitting the contracts and interfaces into different files, but it's not how I personally use the tool, and I didn't want to assume how others might use it
Is there an interest for splitting the output into multiple files? It's not really that hard to implement, and I won't use it myself, but if there are others who need it then why not 😃

namespace from codeGeneratorSettings worked for me with additionalNamespaces, but yeah, output (from openApiToCSharpClient in NSwag Configuration Document) is missing to generate contracts separately from the interface, but I don't know how to place it...
and https://github.com/christianhelle/refitter/issues/184 is missing to completion 😅

namespace from codeGeneratorSettings worked for me with additionalNamespaces, but yeah, output (from openApiToCSharpClient in NSwag Configuration Document) is missing to generate contracts separately from the interface, but I don't know how to place it...

Currently, NSwag returns me a string containing all the generated contracts. I can write this to another file if we can introduce a setting that describes it.
A lot of the options in openApiToCSharpClient are options for how NSwag will generate the API Client and they are irrelevant to Refitter since Refitter generates the Refit interface manually, only using NSwag to parse the OpenAPI spec

and #184 is missing to completion 😅

Coming soon :)

I wonder if it should stay codeGeneratorSettings, maybe contractsGeneratorSettings as you first envisioned it would be better, to indicate it's only for NSwag contracts

I renamed it to codeGeneratorSettings because these settings affect how the OpenAPI spec is parsed, which I use for generating the Refit interface. So if you specify the dateTimeType to be System.DateTime it also affects query string parameters, the same goes for arrayType which can be at times used as a return type to methods in the Refit interface

Not really much left for me to do here so I'll close this issue


Season 8 update

Needs updating for season 8 levels

Worth noting that Leading Light is appearing as a new round for some reason

I just updated to the new v1.127 for this season. Thanks for the quick update!
I still have a few games recorded from maps that aren't properly identified in the program -- they're likely from some of the beta sessions I played in. I'm not sure what the proper names of these maps are. They are named as followed at the bottom of my program:
Bluejay Event 01
Bluejay Event 02
Bluejay Event 03 Final
Follow-The-Leader Ss2 Launch
Would it be possible for you to make the program properly identify these? Would be much appreciated. Thanks again.

I just updated to the new v1.127 for this season. Thanks for the quick update!
I still have a few games recorded from maps that aren't properly identified in the program -- they're likely from some of the beta sessions I played in. I'm not sure what the proper names of these maps are. They are named as followed at the bottom of my program:
Bluejay Event 01 Bluejay Event 02 Bluejay Event 03 Final
Bluejay Events are actually called "Bean Hill Zone" - not sure if the map is called differently when / once it goes into the show rotation

Follow-The-Leader Ss2 Launch
Cannot confirm this one I'm afraid

Would it be possible for you to make the program properly identify these? Would be much appreciated. Thanks again.

Thanks for the update @ShootMe but the season filter is still applying itself to the start of season 7. As well as the issues mentioned above.

I can fix the season filter easily, but I have no real easy way of dealing with the other levels at the time being

Follow-The-Leader SS2 Launch is Leading Light
Gist of player logs for show where it's the second one is available here:
https://gist.github.com/adamkelly86/0558504e38c0d53a2320fe5166307f19

Follow-The-Leader SS2 Launch is Leading Light
Ah, cool. Thanks for figuring it out. 🙂

Hopefully fixed Leading Light in 129


Don't modify proto method names in service paths in Node library

This fixes #4706. I don't remember why I had that there. It does nothing if the method name is already capitalized, and makes the route incorrect when it isn't.

LGTM.

Green enough


MaxLogN=17 issue

Hi,
Is this MaxLogN=17 a limitation of FHE itself or lattigo?
Also another question is I used LogN=18, why the error msg says I'm using LogN=19?

BR

You can remove this hard cap manually by changing the constant.
It says 19 because the actual size of the ring is 2^19 when using the Conjugate Invariant ring (even if in practice only 2^18 coefficients are required).


Fix the issue that values of the item decoration is misplaced

when the user scrolls the RecyclerView.
This was because of the reasons that:

FlexboxItemDecoration#isFirstItemInLine wasn't working correctly (it
expected the flex lines only being calculated in the
FlexboxHelper#calculateFlexLines, not expecting the already calculated
flex lines).

In the layoutFlexLine method in FlexboxLayoutManager,
calculateItemDecorationsForChild needed to be called before added to the
RecyclerView because the view man be created in that method, in that
case calcurated decoration's inset values are not set at the time of
creation.

@yaraki could you have a look?

This should fix #285


Can you please explain how to handle the double spending vulnerability in the doginals protocol for the dog chain?

The contributions of OKX in the field of blockchain are well-known among players and professionals. Therefore, when we learned that OKX is about to support the dog chain with the doginals protocol, which is a legitimate protocol, our team decided to establish a targeted trading market with a background in Dogecoin mining. We have been conducting research in this area for the past month. However, we heard rumors about a double spending vulnerability in the verydogelabs indexing method supported by OKX. During our research, we discovered some evidence supporting these rumors, indicating that some individuals have already taken advantage of this vulnerability in several existing markets, resulting in the loss of millions of Dogecoins. We would like to hear OKX's response and discuss how to address this vulnerability. If this issue is not resolved before the launch of OKX's web3 wallet or if we proceed with establishing a trading market without addressing the vulnerability, it could lead to significant losses for players and even affect OKX's reputation.
We have discovered several dozen addresses on the doggy.market trading platform that are exploiting a double-spending vulnerability by utilizing the verydogelabs index to continuously obtain free DRC20 tokens. These addresses then list these tokens for sale on the market, and each address is making substantial profits. Currently, the trading volume on the doggy market is not significant, but once DRC20 is listed on OKX, we can expect a significant increase in traffic and trading volume. At that point, it will become challenging to control the situation. Moreover, DRC20 has more potential than BRC20, with a larger player base, faster transaction speeds, and lower fees. Once this issue is resolved, we believe OKX will lead this sector comprehensively and be at the forefront of the industry.
Here are some addresses we found from several existing doginals trading markets,The owners of these addresses exploited the double spending vulnerability to acquire a large amount of dog chain doginals and then sell them on the market. These addresses have no minting records or purchase records; they only have records of receiving transfers and selling. Furthermore, these addresses represent only a portion of the issue. We have investigated the communities associated with some doginals and found no evidence of over-the-counter (OTC) trades; they were only traded on the market. Additionally, some players have reported losing a significant amount of their doginals, further confirming the existence of the double spending vulnerability. Currently, our technical team is attempting to verify the vulnerability by testing if our own addresses can be exploited. We hope that OKX will also test and resolve the double spending vulnerability before the launch of the DRC20, as this is crucial.

https://github.com/dogexme/dogim-indexer
This indexer is improved on the basis of doginals and solves the double spending vulnerability, so it is doginals+

You can check out the comment above. Dogim's index perfectly solves these vulnerabilities, and there are many Dogim players. If you can provide a trading market for Dogim, it will definitely be a win-win situation!

Thank you very much for reminding us that we use our own index and will also work with the relevant open source community. If you find any problem with our data, please kindly provide, thank you very much!

Thank you so much for your suggestion！All issues related to the security of user assets should be given high priority. In fact, we have previously discussed some issues with the team from Dogim, and it's unclear what the double-spending case you mentioned here entails. Could you please explain further, or consider joining the Telegram group to discuss which you find here https://t.me/+dNz3fW22kHNhZmZl

@yanminmin , hope you consider DOGIM index as well while integrating doginals from DRC-20 on OKX. We as a community are the bigger part of this DRC-20 ecology and I hope you don't want to lose us.


Illidan has E visual before learning it

Closed by https://github.com/AzerothWarsLR/WarcraftLegacies/commit/ff65f99b7343ea2bd55104667815fee3564ef6be.


Precommit

Add the pre-commit and configurations to run lint checks via the framework, add a GH action for the lint checks, and since most of the infrastructure was now there, add a coverage report to the system. Not hooked to CI, as I couldn't figure out how to grab the resulting report usefully yet.

@steve-downey , does precommit tool can be used for also applying the linter fixes?
e.g. run precommit args... do detect errors and precommit args... --fix to automatically apply (some) changes.
CC: @camio suggested that we should be able to achieve this behaviour with pre-commit, as per my understanding.

@steve-downey , does precommit tool can be used for also applying the linter fixes?
e.g. run precommit args... do detect errors and precommit args... --fix to automatically apply (some) changes.
CC: @camio suggested that we should be able to achieve this behaviour with pre-commit, as per my understanding.

Applying fix-ups is a dependent on the tool being applied and usually the arguments to the tool. I've started with just checks by default and no automatic fixes. There is configured a clang-format fix that will apply changes, in addition to the check of changes, and that can be run to make changes, although it's not that much simpler than a find and xargs or -exec clang-format -i {} \;
I've heard that it's also possible for some fixes to be applied in the PR itself, but I haven't sorted how to do that, or if it's a different tool.

Yes, plan to merge soon.
On Tue, Sep 3, 2024, 06:20 Darius Neațu @.***> wrote:

@.**** approved this pull request.
LGTM 👍
What's the plan with this PR? Will you merge it soon?
—
Reply to this email directly, view it on GitHub
https://github.com/beman-project/Optional26/pull/52#pullrequestreview-2277016671,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAVNZ5QTW2IFVT422D5NXDDZUWEPXAVCNFSM6AAAAABMUXNL5OVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDENZXGAYTMNRXGE
.
You are receiving this because you were mentioned.Message ID:
@.***>


🐛 [Bug report]: Footer Guide Link is broken

Descrcibe the bug?
The guides link in the footer is broken and redirects to https://react-play-docs.netlify.app/docs/intro ( this route does not exist).
Steps to reproduce the bug?

Expected behavior
It should redirect to https://react-play-docs.netlify.app/ instead if https://react-play-docs.netlify.app/docs/intro
Desktop (Please provide your system information)
OS: [e.g. iOS]
Browser [e.g. chrome]
Version [e.g. 113+]
Mobile (Please provide your device information)
No response
Screenshot / Screenshare
No response
Relevant log output
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Can  I fix this issue?

Can I fix this issue?

@ArslanYM , Thanks for your interest but it would great if you start working on the issue once it's assigned to you.

@Sachin-chaurasiya  Sure will keep that in mind next time.


Allow events to limit receivers

Some types of limits come to mind:

specific listener list
only listeners that support specified interface
limited by another function (bouncer type check?)
single receiver (first come)

conditional (3) could be implemented using https://github.com/getnamo/global-event-system-ue4/issues/5 feature.


AC not turning on after successful remote start

Describe The Bug:
2021 Palisade - When remote starting the vehicle the AC settings don't seem to turn on.  The push notification from Hyundai app shows car started with HVAC however the car does start just with no AC. If I use Bluelinky directly with the config below everything works correctly.
Bluelinky Config (Working)
const response = await vehicle.start({
airCtrl: true,
igniOnDuration: 10,
airTempvalue: 65
})
Homebridge-Hyundai-Bluelink Config (Not Working)
"remoteStart": {
"cool": true,
"heat": false,
"defrost": false,
"temperature": 65,
"igniOnDuration": 10
}
To Reproduce:
Use Homekit to start vehicle with the config above
Expected behavior:
Vehicle should start with the HVAC set to 65 degrees
Logs:
Plugin Config:
"remoteStart": {
"cool": true,
"heat": false,
"defrost": false,
"temperature": 65,
"igniOnDuration": 10
}
Screenshots:
Environment:
homebridge-hyundai-bluelink v1.3.9
Raspbian GNU/Linux Buster (10)
v14.17.6
v6.14.15

fixed in https://github.com/athal7/homebridge-hyundai-bluelink/releases/tag/1.3.10


Frontend 4

Topics Covered:
Advanced javascript
Output:

Didn't add the sonar

Always add proper commit messages
Follow this message syntax <branch_name> : "Commit message (a bit descriptive)">
And if too many commits are there then squash them

Good work on the styling

The UI could be better with respect to the Alignment of the TODO items


Docs don't reflect new artifact names

https://bucket4j.com/8.14.0/toc.html#how-to-dependency-to-bucket4j
<dependency>
    <groupId>com.bucket4j</groupId>
    <artifactId>bucket4j-core</artifactId>
    <version>8.14.0</version>
</dependency>

https://github.com/bucket4j/bucket4j/issues/518#issuecomment-2352263419

Not sure if this is the right place for a pr https://github.com/bucket4j/bucket4j.github.io/pull/2
Feel free to close it and point me in the right direction.

Hello @spencergibb
I have merged https://github.com/bucket4j/bucket4j.github.io/pull/2
This is file to fix, so i am going to keep this issue open, until next release when I will have time to fix the original focs.

Thanks! Love the project! Working on new integration in Spring.


stop/start pulse

Is there a way to stop and restart the pulse?

Hey junhohong,
what exactly do you try to achieve? There are several ways to do so or fake that effect. Currently I have no pause and resume method implemented. But you could set the alpha of the animation to zero, set it to hidden, removeAllAnimations of the element that uses that and reattach it again. I can try to implement pause and resume if I get some free time, but won't be able to do it quickly.

I'm trying to activate the pulse on a longtap gesture and remove the pulse when the touch is released.

Do I call removeAllAnimations on the layer it's attached to or the actual imageView? Also, how would I reattach? .insertSublayer?

Thanks for getting back to me so fast btw.

Cannot test it in person right now but the whole thing is a subclass of CALayer. So if you keep a reference to the pulsing CALayer you should be able to remove that specific layer from the view it's lying on. Basically on touchRelease you could do pulseReference.removeFromSuperLayer.
That's a guess in the wild, but should work in theory. Let me know!

I've actually tried that and it does successfully remove the pulse. However my problem is starting up the animation again - I've tried initializing the animation again and inserting it to the sublayer, keeping the same animation and inserting it to the sublayer -- both did not work :(

That's weird. Could you attach a code example? I would think at least reinirializing it again and add it as a sublayer  should work properly.

On longhold:
let pulseEffect = LFTPulseAnimation(repeatCount:Float.infinity, radius:60, position: CGPoint(x:pulseView.frame.width/2,y:pulseView.frame.height/2))
pulseView.layer.insertSublayer(pulseEffect, below: pulseView.layer)

On release:
pulseView.layer.sublayers?.forEach{$0.removeFromSuperlayer()}

Exiting and entering the app again makes it work, could be a lead

could you please try the following:
Save the reference to the pulse effect and then do the following:
On release:
pulseEffect.removeFromSuperLayer()
So don't traverse through layer hierarchy and remove every sublayer but just the pulseEffect layer.

I've tried that as well, same effect :(

I am on the run so can't look deeper into it. But it's a standard CALayer, whatever is wrong there should also not work with a normal CALayer. Did you try it with a simple CALayer if it behaves the same?

Thanks for helping out. I'll try that.

Simple CALayer behaves the same...

Figured it out!!!! One of my other animations was interfering with it for some reason.

Happy that you could resolve the problem! Happy coding!


WIP: End to End test for vision and audio

Started working on adding end to end tests for audio and vision. #378
Most of the test cases cover sending URLs to the endpoints, because based on my observation this is the only supported mode of operation.
I added a test case which shows the behaviour of sending only text named test_{audio,vision}_single_text_only. Sending text results in a 422 Status response.
Looking through the code it seems the pydantic layer only accepts URL formated strings: See here
Even with disabled pydandic checks it seems theres only suport for url or list of urls based on this code

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 72.57%. Comparing base (6c1ad68) to head (074105d).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

:exclamation:  There is a different number of reports uploaded between BASE (6c1ad68) and HEAD (074105d). Click for more details.
HEAD has 9 uploads less than BASE

Flag
BASE (6c1ad68)
HEAD (074105d)

10
1

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #386      +/-   ##
==========================================
- Coverage   77.78%   72.57%   -5.21%
==========================================
  Files          37       37
  Lines        2804     2804
==========================================
- Hits         2181     2035     -146
- Misses        623      769     +146

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Looks good to me!


emote/emoji break randomly

if an emote/emoji is posted to chat, sometimes the site will break, and shows the sanitized html, instead of rendering the emote (see pic)

I have the same problem. If it can be fixed, this project would be near perfect!


Report violations of ThrowsCount also in override functions (#6752)

Fixes #6752.

Warnings

:warning:
This PR is approved with no milestone set. If merged, it won't appear in the detekt release notes.

  Generated by :no_entry_sign: dangerJS against 4c5558cf27d1100ac3e0a144cd041ff5c79e942c


Multiple Image Tags (DO NOT MERGE)

Draft PR to facilitate tagging discussion.

Superseded by #34


With list type value , it  is not randomizing with "in" feature !

Hello, I have tried following code and in that I have used for one variable "b", constraint I have provided with list  type instead of in vsc.rangelist , but it is not randomizing the value of b variable:

and following is the output for this code:

So, can you please put some light on this?

Hello,
The short answer is that PyVSC doesn't yet support the 'in ' constraint. The 'in' constraint currently supports vsc.rangelist on the right-hand side.
I've been investigating the behavior you're currently seeing, and I'm not entirely sure I understand the root cause. Basically, the 'self.b in self.temp' statement is being converted by Python into 'self.b == self.temp[0]'.
If supporting the 'in' constraints on lists is important to you (seems it is), please open an enhancement request to support this.

Thanks and Best Regards,
Matthew

Yes Matthew, actually we need this feature and many more which I will update you like this. So,can you please open enhancement request on this, because I don't have write access to repo, you can only do this.

Hi Shraddha,
Sounds good. Please open an issue (just like this one) requesting 'in list' support. My reason for asking you to open the issue is that you'll be notified when the feature is supported.
Thanks and Best Regards,
Matthew

okay. Let me do it ! Thanks for your support @mballance .

Hi @mballance , I tried to install pyvsc 0.0.4 with pip3, but still it is installing 0.0.3 version. So Can you please take a look at it?

Hi @ShraddhaDevaiya, I double-checked on this and it seems I forgot to bump the version. The version is updated, which will ensure that a new release is available on PyPi. Apologies for the delay, and hope the new release works for you!
Best Regards,
Matthew

Hello @mballance , I am able to install the<EMAIL_ADDRESS>but it is not randomizing the  value of self.b from the list temp. Same result  I am getting , which is shown below :

and one more thing, we can observe here, printing of set value. I have not written it in code. So, any significance of this ?

for set value , I got the thing, I have used list inside rangelist instead of tuple, as you said new release it should be tuple. But self.b value is not randomizing. Can you please confirm this?


linux: fix support for preadv/pwritev-less kernels

The fix from commit 269ff0be is wrong in that it sniffs system headers
to determine if preadv() and pwrite() are supported.
It breaks the fs_write_multiple_bufs test on one of my ARM systems;
its glibc has preadv() and pwritev() wrappers but its kernel has no
support for the corresponding system calls.
Simply try the system call and fall back to a normal read or write
loop if not supported.  Move the no_preadv and no_pwritev variables
around to squelch two -Wpedantic warnings about mixing declarations
with code.
R=@saghul

LGTM, sorry for the delay, Ben, I didn't know you could put labels so freely. Now I know!

LGTM, sorry for the delay, Ben, I didn't know you could put labels so freely. Now I know!

Sorry, I botched the initial push.  Landed in af96f45, thanks!


[Polymetis] Fix signal handler in RobotInterface

Description

Add a test for a multi-threaded environment for RobotInterface.
Remove signal handler

Fixes #899
Type of change
Please check the options that are relevant.

[x] Bug fix (non-breaking change that fixes an issue)
[ ] Proposes a change (non-breaking change that isn't necessarily a bug)
[ ] Refactor
[ ] New feature (non-breaking change that adds a new functionality)
[ ] Breaking change (fix or feature that would break some existing functionality downstream)
[ ] This is a unit test
[ ] Documentation only change
[ ] Datasets Release
[ ] Models Release

Type of requested review

[x] I want a thorough review of the implementation.
[ ] I want a high level review.
[ ] I want a deep design review.

Before and After
If this PR introduces a change or fixes a bug, please add before and after screenshots (if this is causes a UX change) or before and after examples(this could be plain text, videos etc ) to demonstrate the change.
If this PR introduces a new feature, please also add examples or screenshots demonstrating the feature.
Testing
Please describe the tests that you ran to verify your changes and how we can reproduce.
Checklist:

[ ] I have performed manual end-to-end testing of the feature in my environment.
[ ] I have added Docstrings and comments to the code.
[ ] I have made changes to existing documentation where needed.
[ ] I have added tests that show that the PR is functional.
[ ] New and existing unit tests pass locally with my changes.
[ ] I have added relevant collaborators to review the PR before merge.
[ ] [Polymetis only] I have verified that all scripts in tests/scripts runs on hardware.

@exhaustin The original pull request is here. I believe I was following the gRPC Python documentation in an effort to cancel the RPC on exit.

Codecov Report

Merging #908 (ba6c3e7) into main (f5eb0c5) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #908   +/-   ##
=======================================
  Coverage   32.43%   32.43%
=======================================
  Files         343      343
  Lines       33349    33349
=======================================
  Hits        10818    10818
  Misses      22531    22531


lvm: implement non-thinpool based storage pools

Signed-off-by: Christian Brauner<EMAIL_ADDRESS>

Closes #3160.


[feat] Add onboarding feature - adding three anonymized document

.. plus opening the AI commands after parsed
Showing tiles with most common actions on dashboard

show 4 tiles on the main screen of chat where there no messages yet

... add single folder to new database so the user doesn't have to add it

It should be like - creating a new database from template -static files + database content


add postinstall hook for in-repo add-ons

idea to help with in-repo addons. Maybe something we want to add to ember-cli...

Awesome! Thank you, I'm glad my problems are giving you ideas!

Awesome! Thank you, I'm glad my problems are giving you ideas!

this is how we make stuff better.
This app is great :)


Please support http proxies for OCSP

Hi,
openssl does not respect the usual ALL_PROXY/HTTPS_PROXY environment variables.
Here is some example code that shows how to use proxies with openssl for requesting ocsp files:
https://github.com/bzed/bzed-letsencrypt/blob/master/templates/letsencrypt_get_certificate_ocsp.sh.erb
Thanks,
Bernd

If you really need this please submit a pull-request implementing this (also setting proxy for curl etc.). I've never had somebody else asking this and i think the suggested solution is a bit ugly... That might also cause issues with some OpenSSL versions as some don't support the header argument, which actually just recently caused issues with LibreSSL.


layers: Ensure that at most one push descriptor set layout is used

@jozefkucia, if you wouldn't mind, the first line in commit messages should be right at 50 characters in length -- please see the CONTRIBUTING.md doc in the repo.


Thermostat

@t0mg, just wondering if it is possible to change the behaviour of the thermostat widget a bit.
Currently every press on the button of the widget sends a command directly.
This means that if you set the thermostat from 18.5 to 17.0 there are 3 commands send, as the Domoticz log below shows.
2017-02-04 00:26:52.223 ICYThermostat: Setting Room SetPoint to: 17.0 2017-02-04 00:26:51.996 Sending SetPoint to device.... 2017-02-04 00:26:51.983 ICYThermostat: Setting Room SetPoint to: 17.5 2017-02-04 00:26:51.316 Sending SetPoint to device.... 2017-02-04 00:26:51.031 ICYThermostat: Setting Room SetPoint to: 18.0 2017-02-04 00:26:50.787 Sending SetPoint to device....
I think it would be more logical to use the same way as Domoticz changes the setpoint.

So you first select the right temp and then you click the button to set that temp. This means only one command is being sent.
What do you think?

The way reacticz works is that the interface reflects the state of the devices in real time. Clicking an on off button doesn't change the color if the button, it sends the toggle command and Domoticz returns an MQTT message withe the status update which is received by reacticz, finally updating the state of the button. This ensures that what you see is always in sync with the actual state of the devices (and that makes reacticz faster than the regular dashboard or even the mobile app). So with the thermostat I understand your concern but decoupling the value of the widget from the true state of the device is something I'm not super found of. However, there is one exception : on dimmer switch I do some throttling to limit the number of commands reacticz sends, this is why there is a bar that gives immediate feedback, and the progress thing behind is a bit late behind but reflects what Domoticz actually sends back. We could implement something similar on the thermostat, for example using an alternative color for the temperature when it's being changed, then wait for a little delay and send the command. When the "true" value comes back from Domoticz the widget would switch back to regular color.

That sounds like an excellent solution!

I chose to make it blink instead of change color, this avoids adding a new color in the theme just for that, and is a familiar pattern when setting digital clocks and counters.

Very nice! Thanks for implementing.
Works great this way :)


[FeedExpander] Handle Atom enclosures

Tried to chain the WordPress bridge with the Filter bridge and noticed that enclosures were gone.
The FeedExpander component was the culprit: it does not pass on Atom enclosures. This PR aims to fix that.

Nice catch @ORelio !


Snapshot Query History

Snapshot query history for tables (mart only?) that are being observed

Looks like Snowflake can get down to the table column level:
https://docs.snowflake.com/en/sql-reference/account-usage/access_history


Investigate xmp_files_check_file_format with PDF, ILLUSTRATOR

test_format_pdf and test_format_illustrator are skipped because the library function xmp_files_check_file_format function seems to fail on those two formats.  Needs better explanation/documentations than what currently exists.

Duplicate of #40, interestingly enough


Replace custom type with Infallible

Now we have bumped the MSRV we can use Infallible instead of defining our own custom type.
Includes custom implementation of Hash using unreachable!.

We could just manually implement Hash.
I don't like the idea of removing it, but OTOH I can't imagine why it's there in the first place..

Ah, I didn't realize how low-touch this PR was already.
IMO we should do it, and just make Hash a manual implementation.

Ah, I didn't realize how low-touch this PR was already.

Me no English good, what do you mean by 'low-touch'?

IMO we should do it, and just make Hash a manual implementation.

Cool, will do. Cheers.

We could just manually implement Hash.

In hindsight I don't know why I didn't think of this, doing so was trivial :)

Oh, looking at it now, it actually can be just removed together with BitcoinConsensusError and replaced with conditional variant plus #[non_exhaustive].

Ah lolz, that's so funny, originally we lamented not having  non_exhaustive when doing this PR didn't we. Funny I forgot, thanks for noticing.

Left a comment for learning opportunity.

Cheers man!