Batch Support

Support for batches in SolidQueue!
Batches are a powerful feature in Sidekiq Pro and GoodJob which help with job coordination. A "Batch" is a collection of jobs, and when those jobs meet certain completion criteria it can optionally trigger another job with the batch record as an argument.
The goal of this feature is to:

Enhance job coordination
Maintain the overall simplicity of SolidQueue. To quote @rosa in the batch support issue:

We have batch support in our list of possible features to add, but it's not in the immediate plans because it's a bit at odds with the simplicity we're aiming for... I'm not quite sure yet how it could look like, in a way that maintains the overall simplicity of the gem

This PR provides a functional batch implementation. The following scenarios will work:
# Create a job to run as part of the batch
class SleepyJob < ApplicationJob
  queue_as :background

  def perform(seconds_to_sleep)
    Rails.logger.info "Feeling #{seconds_to_sleep} seconds sleepy..."
    sleep seconds_to_sleep
  end
end

# Create a batch completion job - the first argument is always the batch record itself
class BatchCompletionJob < ApplicationJob
  queue_as :background

  def perform(batch)
    Rails.logger.info "#{batch.jobs.size} jobs completed!"
  end
end

# Create the batch itself. There are three callback options: `on_finish`, `on_success` and `on_failure`
SolidQueue::JobBatch.enqueue(on_success: BatchCompletionJob) do
  5.times.map { |i| SleepyJob.perform_later(i) }
end

You should see the following in your logs:
[SolidQueue] Claimed 5 jobs
Performing SleepyJob (Job ID: 9a97e394-f1b4-47b5-8db3-6df86faf0913) from SolidQueue(background) enqueued at 2024-02-02T02:02:05.563284000Z with arguments: 1
Feeling 1 seconds sleepy...
Performing SleepyJob (Job ID: 4ae76794-25e1-4378-bbc7-c505d7775395) from SolidQueue(background) enqueued at 2024-02-02T02:02:05.567448000Z with arguments: 2
Feeling 2 seconds sleepy...
Performing SleepyJob (Job ID: fd41b240-08b6-4f7d-b4de-38ee2e6a58b4) from SolidQueue(background) enqueued at 2024-02-02T02:02:05.557246000Z with arguments: 0
Feeling 0 seconds sleepy...
Performed SleepyJob (Job ID: fd41b240-08b6-4f7d-b4de-38ee2e6a58b4) from SolidQueue(background) in 0.1ms
Performing SleepyJob (Job ID: 40498973-9b5a-4f57-acce-03e2b8e2a97c) from SolidQueue(background) enqueued at 2024-02-02T02:02:05.594398000Z with arguments: 4
Feeling 4 seconds sleepy...
Performing SleepyJob (Job ID: c2a123ea-61ba-4d33-99e7-9478a8ca4f5d) from SolidQueue(background) enqueued at 2024-02-02T02:02:05.589439000Z with arguments: 3
Feeling 3 seconds sleepy...
Performed SleepyJob (Job ID: 9a97e394-f1b4-47b5-8db3-6df86faf0913) from SolidQueue(background) in 1005.47ms
Performed SleepyJob (Job ID: 4ae76794-25e1-4378-bbc7-c505d7775395) from SolidQueue(background) in 2006.58ms
Performed SleepyJob (Job ID: c2a123ea-61ba-4d33-99e7-9478a8ca4f5d) from SolidQueue(background) in 3006.1ms
Performed SleepyJob (Job ID: 40498973-9b5a-4f57-acce-03e2b8e2a97c) from SolidQueue(background) in 4008.12ms
[SolidQueue] Claimed 1 jobs
Performing BatchCompletionJob (Job ID: 625ca70c-4e80-4789-988b-3950ed1b23f3) from SolidQueue(background) enqueued at 2024-02-02T02:02:10.183075000Z with arguments: #<GlobalID:0x000000010b5b0390 @uri=#<URI::GID gid://dummy/SolidQueue::JobBatch/13>>
5 jobs completed!
Performed BatchCompletionJob (Job ID: 625ca70c-4e80-4789-988b-3950ed1b23f3) from SolidQueue(background) in 7.97ms

Here is the full interface, demonstrating a few different options:
# All three callback types
# on_finish: runs after all jobs have finished running, including retries. It runs regardless of failed jobs
# on_success: runs after all jobs have finished running, including retries. Only runs if all jobs succeed
# on_failure: runs once, the _first_ time any job fails
SolidQueue::JobBatch.enqueue(
  # You can hand in a populated instance, to set options like wait times or a custom queue for the callback
  on_finish: BatchCompletionJob.new.set(wait_until: 1.hour.from_now, queue: :batch),
  # Otherwise just supply the job class
  on_success: BatchSuccessJob,
  on_failure: BatchFailureJob
) do
  5.times.map { |i| SleepyJob.perform_later(i) }
end

# Jobs that are part of a batch can enqueue more jobs into the batch
class EnqueueMoreJobsJob < ApplicationJob
  def perform
    batch.enqueue { YetAnotherJob.perform_later }
  end
end

# Batches can be nested. Outer or "parent" batches will not complete until all child batches have completed
SolidQueue::JobBatch.enqueue(...) do
  # finishes third
  SolidQueue::JobBatch.enqueue(...) do
    # finishes second
    SolidQueue::JobBatch.enqueue(...) do
      # finishes first
    end
  end
end

Here are the things that are open questions and missing implementation details:

[ ] Naming: is JobBatch the right name? General feedback on naming in the feature
[ ] Is it simple enough?
[ ] Do the callbacks make sense? on_success, on_finish, on_failure
[ ] We cannot handle discards right now. SolidQueue handles discard_on by marking the job as finished. That means the batch cannot identify that the job actually failed.
[ ] Hand a generalized interface into the job instead of an actual batch record?
[ ] Keeping things efficient when you have tons of jobs in a batch
[ ] How would/could batches fit into Mission Control - Jobs? https://github.com/jpcamara/mission_control-jobs/pull/1
[ ] All other feedback 🙇🏼

Could that also support adding jobs to already existing batch? Like SleepyJob enqueuing another job that would also be added to the batch.

Could that also support adding jobs to already existing batch? Like SleepyJob enqueuing another job that would also be added to the batch.

Definitely. As long as you're in a job that's part of the batch, adding another job to the batch would work fine. It'd be pretty simple to extend the existing code to handle that - something like this would solve your use-case I think?
class SleepyJob < ApplicationJob
  queue_as :background

  def perform(seconds_to_sleep)
    Rails.logger.info "Feeling #{seconds_to_sleep} seconds sleepy..."
    sleep seconds_to_sleep

    batch.enqueue { AnotherJob.perform_later }
  end
end

We could update the ActiveJob::JobBatchId to add an extra batch method which returns the current batch based on the job batch_id, and add an instance level SolidQueue::JobBatch#enqueue method which let's you add more jobs to the batch.

Yes that would absolutely do the trick for me :) Thank you!

Hi @rosa 👋🏼 Congrats on getting SolidQueue past incubation and under the Rails umbrella officially!
I'm sure you've got alot on your plate! Is there any questions I can answer in regards to this PR? I can take the interface/functionality further, but I wanted to discuss it a bit before doing that. If there's anything additional you'd like me to tighten up/try out before discussing it, i'm happy to do so.
Also ok to just be on hold and not ready to discuss this further atm. Since it's been a couple months, I figured i'd check in.

Hey @jpcamara, so sorry for the delay and the silence here. I just haven't had the proper time to dedicate to this, and I think this requires more than a quick look.
My instinct with this kind of feature is that they require someone to use them before they're ready. From just looking at the code, I'm not quite sure what kind of edge cases and race conditions could arise here. This is how most of Solid Queue has been built: we've used it in HEY before making it "official" for everyone, seeing how it behaves under certain loads and what kind of problems we encounter. We caught and improved quite a few things that way.
We don't have a use case for batches right now, so I'm afraid I won't be able to take this feature to this "production-test" point on my side. Do you see yourself using this in a production setting?

Hey @jpcamara, so sorry for the delay and the silence here. I just haven't had the proper time to dedicate to this, and I think this requires and deserves more than a quick look. Thank you so much for putting this together!
My instinct with this kind of feature is that they require someone to use them before they're ready. From just looking at the code, I'm not quite sure what kind of edge cases and race conditions could arise here. This is how most of Solid Queue has been built: we've used it in HEY before making it "official" for everyone, seeing how it behaves under certain loads and what kind of problems we encounter. We caught and improved quite a few things that way.
We don't have a use case for batches right now, so I'm afraid I won't be able to take this feature to this "production-test" point on my side. Do you see yourself using this in a production setting?

That makes sense! It was a bit of a chicken and an egg issue for me - I wanted to have batches in SolidQueue before starting to transition some things over, because I have code using Sidekiq Pro batches. But I can start experimenting with it now and report back. I'll continue to work on this PR as well in that case, too.

Thanks for all the hard work here. I'm a big fan of batch jobs so I've been keeping my eye on this PR for a while. Sidekiq Pro and others support the notion of child batches. Like batch jobs, child batches let you work with a higher level abstraction that conceptually simplifies your background work. While implementing that in this PR would be feature creep, I wanted to raise awareness of it in hopes that we design with its extensibility in mind.
Thanks again @jpcamara

Thanks for all the hard work here. I'm a big fan of batch jobs so I've been keeping my eye on this PR for a while. Sidekiq Pro and others support the notion of child batches. Like batch jobs, child batches let you work with a higher level abstraction that conceptually simplifies your background work. While implementing that in this PR would be feature creep, I wanted to raise awareness of it in hopes that we design with its extensibility in mind.
Thanks again @jpcamara

hey @dimroc! I couldn't agree more. I used child batches in Sidekiq recently in a project and it highlighted the need to add them to this PR - it's an important feature. I've been putting alot of work releasing a blog series on ruby concurrency and it's been eating up my free coding-related time, but i'm prioritizing getting back to this soon. Thanks for the feedback!

Thanks for all the hard work here. I'm a big fan of batch jobs so I've been keeping my eye on this PR for a while. Sidekiq Pro and others support the notion of child batches. Like batch jobs, child batches let you work with a higher level abstraction that conceptually simplifies your background work. While implementing that in this PR would be feature creep, I wanted to raise awareness of it in hopes that we design with its extensibility in mind.
Thanks again @jpcamara

hey @dimroc! I couldn't agree more. I used child batches in Sidekiq recently in a project and it highlighted the need to add them to this PR - it's an important feature. I've been putting alot of work into releasing a blog series on ruby concurrency and it's been eating up my free coding-related time, but i'm prioritizing getting back to this soon. Thanks for the feedback!

I've added nested batches to this PR @dimroc

@jpcamara just an idea here. Could this functionality become its own gem? Like an add-on for solid_queue?
I'm currently using Gush, which is similar to what this functionality does.

One place I think this could be useful could be rolling back changes. Since the move to SQLite doesn't create jobs to a secondary database until after committing records to the main database, there is no atomic guarantee that both records will commit to both databases, leaving us to need manual rollback logic. Additionally, this reminds me that sidekiq had some atomic writing of batch jobs guarantee, either in pro or enterprise.
Same thing might happen if you make a change in your database and call an external API. With SQLite you no longer want to make those changes in your database and make the [long-running] external API call in a transaction. Let's say you have to call stripe twice and want to keep a record of what stage you're at. But something goes wrong with the second stripe call (say the charge is declined) and you need to rollback your database so it's not in an inconsistent state.
In this case you can queue the rollback as part of the batch.
If memory serves, I think the pattern for this sort of thing is called Sagas, or a DAG such as Elixir has with GenStage.

@jpcamara just an idea here. Could this functionality become its own gem? Like an add-on for solid_queue? I'm currently using Gush, which is similar to what this functionality does.

@mariochavez it's true, it probably could be a gem! Sidekiq has batches as a pro feature, but there is also an open-source gem that mostly supports the same api https://github.com/breamware/sidekiq-batch.
There are some gotchas with approaching it that way (one, for instance, around jobs being automatically cleaned up and not being able to do anything but warn users against it). But my main motivation is that I personally want it as a first-class feature of SolidQueue. It's a first-class (albeit paid) feature of Sidekiq, and it's a first-class feature of GoodJob. Being built-in means it's more likely to get use/support and alleviates concerns it may be abandoned at some point. I also think it's a great core feature of a job library.
Gush is awesome! It definitely works similarly, though this being backed by a DB in SolidQueue means it has more ACID-type guarantees.
Something I would like to see is an event more sophisticated "workflow" type layer that worked with any activejob system, and that's something I've toyed around wtih over the past year. That kind of system I think goes a step beyond, is more complicated, and is better served as a separate gem. I think batch support being included in the job server is a good fit.

Thanks for all this work @jpcamara!
I'm curious what the expected behavior is with limit_concurrency. Does it limit concurrency until the batch is complete (ie: only 3 batch jobs can run concurrently), which would surpass even Sidekiq's behavior, or does that only work with individual jobs? An argument for keeping this in the main gem is to increase stability and cohesion (integration testing, etc) with all the other features. I can see it getting hairy when you stack a few different configurations on top of nested batches, and having to assert proper behavior.
https://github.com/rails/solid_queue?tab=readme-ov-file#concurrency-controls

I would love to see batches in Solid Queue! My use case is primarily creating workflows.

Just wanna thank @jpcamara for the work he's done, is doing here. Would love to use this 🙏

I wanted to test this but it's 275 commits behind solid queue, @jpcamara if you can update to the latest, I'll be happy to test this in production

Just wanna thank @jpcamara for the work he's done, is doing here. Would love to use this 🙏

Hey @kaka-ruto, I think I saw a message about you being willing to try this out? That would be great! Most of my free time is working on a RubyConf talk I have in a couple weeks, but i'll be shifting back to this right after that and will give you an update.

@jpcamara loved your talk on ruby concurrency, so even more thrilled to see your name against this PR. We make heavy use of jobs (using GoodJob currently) and batching is the only critical feature we're missing switching to solid_queue. Are you still planning on working on this PR and trying to get it merged?


quick restart container when kubeconfig changed

Signed-off-by: zhujian<EMAIL_ADDRESS>

/close


watson 1.5.2's setup.py fails on gentoo linux.

With python 2.7, python 3.5, and python 3.6, when setup.py is executed, I see the same error message.

error in td-watson setup command: 'install_requires' must be a string or list of strings containing valid project/version requirement specifiers; Unordered types are not allowed

setup.py on the latest git commit doesn't have this issue.

It seems https://github.com/TailorDev/Watson/pull/175 fixed this issue.


bot join room

can i invite the bot to join rooms? seems like currently i need to login as bot on a matrix client and then accept invite.

Bot will automatically accept join room invitation.

yes, my mistake. now works perfect


Enhance scam warning

I also received a scam email, as described in #98. In #99, a warning was added to the README. This PR enhances that warning in two ways.

Explicitly makes the part #98 link to #98, because this does not happen automatically in READMEs, and some people may not know that #98 is supposed to link to an issue.
Use GitHub-flavoured Markdown alert to make the warning more visible.

I also fixed what I think was a typo in the first sentence.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks!


Missing settings warning when offline

From @roblourens on April 24, 2018 17:12
Testing #48391

Install the beautify extension
Create an extension with an "application" scope setting, following #48391
Go offline
Set that setting in the workspace settings.json
There is a warning that the beautify json schema can't be downloaded, but no warning about the application scoped setting

If you disable the beautify extension, then the warning is shown properly even when offline. So it seems like the other missing schema is interfering even though it shouldn't matter for this case.
Copied from original issue: Microsoft/vscode#48572

From @sandy081 on April 25, 2018 8:10
@aeschli Known?

Looks like a bug in the beautify extension.
It uses a external ref in the schema: https://github.com/HookyQR/VSCodeBeautify/blob/63b6a2261efc07af7dd7e9df6920f499da54f97c/package.json#L51

Please do not use $ref in configurations but inline all what is necessary.

Well, that's double handling and prone to error. Perhaps you (vscode) should download the reference and keep it for offline access, updating when back on line of course.
I'm surprised the extension writer should 'copy and paste' is your answer here. Especially since the system is set up for the $ref to work.

Have embedded the settings. They're now replicated in three places.


S3 delete objects ray support

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-pDO66x4b9gEu
Commit ID: 8963b128348f86cfa330942c13d55fc0f0684f86
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GithubDistributedCodeBuildA-JqJZwMMy1Awv
Commit ID: cc48403ed746f01b9dae4fcbd89cc22f045e3d4d
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GithubDistributedCodeBuildA-JqJZwMMy1Awv
Commit ID: 17666a01010958a807bb65de1934cf3427f2f293
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


Update PolyPartition / Triangulator library

This PR updates the PolyPartition library (previously the files were called "triangulator") to commit 7bdffb4.
The only difference between the version in the repo and the version in this PR is that this PR uses Godot's types (List, Set, Vector, Vector2) instead of the standard library (std::list, std::set, std::vector) and PolyPartition's TPPLPoint.

The only difference between the version in the repo and the version in this PR is that this PR uses Godot's types (List, Set, Vector, Vector2) instead of the standard library (std::list, std::set, std::vector) and PolyPartition's TPPLPoint.

Why? We shouldn't modify thirdparty code if we don't have to, and that's a very intrusive change to thirdparty code, making it difficult to do any future update.

The only difference between the version in the repo and the version in this PR is that this PR uses Godot's types (List, Set, Vector, Vector2) instead of the standard library (std::list, std::set, std::vector) and PolyPartition's TPPLPoint.

Why? We shouldn't modify thirdparty code if we don't have to, and that's a very intrusive change to thirdparty code, making it difficult to do any future update.

@akien-mga Well, because the existing version in Godot was using Godot's types, so I kept that part the same.
It should be easy to change it back to using the standard library by just copying the upstream version again, though in the case of TPPLPoint I think it makes sense to keep using Godot's Vector2 since it's a drop-in replacement with one typedef.

@akien-mga Well, because the existing version in Godot was using Godot's types, so I kept that part the same.
It should be easy to change it back to using the standard library by just copying the upstream version again, though in the case of TPPLPoint I think it makes sense to keep using Godot's Vector2 since it's a drop-in replacement with one typedef.

I see. Then I guess it's fine for this PR, but yeah I think a follow-up could try to undo all these Godot-specific changes and use the unmodified thirdparty code. If we need to write a Vector2 wrapper around TPPLPoint that can be done too.
Could you update thirdparty/README.md with the rename and the actual version documentation, now that it's known?

I see. Then I guess it's fine for this PR, but yeah I think a follow-up could try to undo all these Godot-specific changes and use the unmodified thirdparty code. If we need to write a Vector2 wrapper around TPPLPoint that can be done too.
Could you update thirdparty/README.md with the rename and the actual version documentation, now that it's known?

Could you also add a .patch file that documents the changes made to change from STL to Godot types? You can do it by backing up your modified files, adding the unmodified upstream code on top, git add it, then re-copy your modified files on top and git diff > thirdparty/misc/patches/polypartition-godot-types.patch.

Could you also add a .patch file that documents the changes made to change from STL to Godot types? You can do it by backing up your modified files, adding the unmodified upstream code on top, git add it, then re-copy your modified files on top and git diff > thirdparty/misc/patches/polypartition-godot-types.patch.

I will do that, keeping a .patch file is a good idea.
I looked into what it would take to keep std::. We would have to update the Godot code that depends on this to use the standard library, and add conversions to and from Godot types for the input and output of methods such as Geometry2D::decompose_polygon_in_convex, so I think that's not a good idea.

I will do that, keeping a .patch file is a good idea.
I looked into what it would take to keep std::. We would have to update the Godot code that depends on this to use the standard library, and add conversions to and from Godot types for the input and output of methods such as Geometry2D::decompose_polygon_in_convex, so I think that's not a good idea.

In Goost, I've exposed quite a bunch of hidden PolyPartition functionality, and discovered that there's actually a hidden bug in Triangulate_MONO (with Godot types): https://github.com/goostengine/goost/blob/c5ef6734b87057f0d73ca0fcbd6c3a50c862480c/core/math/2d/geometry/poly/decomp/polypartition/poly_decomp_polypartition.cpp#L94-L98
This is also something which #16423 proposed to enable over ear-clipping which is currently the default (would mostly avoid "Bad Polygon!" errors while drawing polygons).
So, I'm just saying that I'd be careful modifying thirdparty code, and yeah I'd certainly prefer to undo those Godot-specific changes because there's a high chance of breaking things that way, especially when the library is updated.

add conversions to and from Godot types for the input and output of methods such as Geometry2D::decompose_polygon_in_convex, so I think that's not a good idea.

That's how Clipper library is currently used in Godot for polygon boolean methods (mainly due to the way how points needs to be scaled up and down to achieve robust computations), and it's quite fast even with conversion going on.
This is something which can be done via dedicated PR though.

In Goost, I've exposed quite a bunch of hidden PolyPartition functionality, and discovered that there's actually a hidden bug in Triangulate_MONO (with Godot types): https://github.com/goostengine/goost/blob/c5ef6734b87057f0d73ca0fcbd6c3a50c862480c/core/math/2d/geometry/poly/decomp/polypartition/poly_decomp_polypartition.cpp#L94-L98
This is also something which #16423 proposed to enable over ear-clipping which is currently the default (would mostly avoid "Bad Polygon!" errors while drawing polygons).
So, I'm just saying that I'd be careful modifying thirdparty code, and yeah I'd certainly prefer to undo those Godot-specific changes because there's a high chance of breaking things that way, especially when the library is updated.

add conversions to and from Godot types for the input and output of methods such as Geometry2D::decompose_polygon_in_convex, so I think that's not a good idea.

That's how Clipper library is currently used in Godot for polygon boolean methods (mainly due to the way how points needs to be scaled up and down to achieve robust computations), and it's quite fast even with conversion going on.
This is something which can be done via dedicated PR though.

@Xrayez If you would like to add onto this PR, that would be nice too. It would result in fewer diffs than if this PR was accepted as it is now and then these files were changed and the patch deleted.

@Xrayez If you would like to add onto this PR, that would be nice too. It would result in fewer diffs than if this PR was accepted as it is now and then these files were changed and the patch deleted.

I'd certainly work on this but unfortunately I'm not using Godot 4.0 currently so it seems like such a low-priority task to be honest... I think it's fine to have those Godot types for now. Perhaps this update may fix the crash with Triangulate_MONO and this wouldn't be critical any longer. It's just something to be ever of.

I'd certainly work on this but unfortunately I'm not using Godot 4.0 currently so it seems like such a low-priority task to be honest... I think it's fine to have those Godot types for now. Perhaps this update may fix the crash with Triangulate_MONO and this wouldn't be critical any longer. It's just something to be ever of.

Thanks!

Thanks!


Update design-requirements.md

There're duplicated Mean Time Between Failures (MTBF) . I removed one of them and add Mean time to recover (MTTR) metric for determine SLA.

@mustafakaya : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#Sign-Off

@EdPrice-MSFT: I'm sorry - only the author of this article, @v-aangie, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


fix title font issue

See this snapshot from the wayback machine --- somehow the font face/color updated from bold/green to normal/black with this commit?
alternative is just to rollback the changes and do in a separate branch like I should've done. Don't push to main kids

closed by 0f549bb


fix(service subscription): change header name

Description
Changed 'Active Service Subscription' overlay section header for 'Technical User Details'
Why
Header name was duplicated
Issue
https://github.com/eclipse-tractusx/portal-frontend/issues/494
Checklist
Please delete options that are not relevant.

[x] I have followed the contributing guidelines
[x] I have performed a self-review of my own code
[x] I have successfully tested my changes locally

conflict in changelog

@evegufy Resolved.


Extract wordnet into a separate package

@alvations has created https://github.com/nltk/wordnet
We need to deprecate the existing NLTK wordnet corpus reader

@fcbond any advice on this?

I've been consulting with @alvations and @fcbond to work on an entirely new wordnet module: https://github.com/goodmami/wn. It's not yet feature-complete nor documented (contributions are welcome), but the basics are working fairly well.
It better adheres to the Word–Sense–Synset structure used by wordnets instead of the Lemma–Synset simplified structure used by the NLTK module. As such, the API isn't exactly the same as the NLTK module or the spun-out wordnet module.
What is the plan regarding the NLTK? Will there no longer be an NLTK wordnet module? Or is the hope to replace it with a new one? If the latter, are there requirements regarding the API?

Hi, returning to this with an update: the Wn library has been, since shortly after my last comment, documented and reasonably feature-complete since the 0.8.0 release about four months ago. Recently I've been working on increasing compatibility with the NLTK's wordnet, on two fronts:

A (mostly trivial) Python shim module that implements the NLTK's API on top of Wn's
Updating the OMW's data to fix some regressions in its export of the WordNet 3.0 data and so we can recreate the NLTK's synset identifiers (e.g., dog.n.01)

The idea is that these two things would allow it to pass the NLTK's doctests. I never got a response to my questions above, so I'm not sure if the goal was to integrate the new system into the NLTK or to just change the documentation to refer to it. There was some more discussion at nltk/nltk_data#160.
Meanwhile it seems that @ekaf has been also doing good work (https://github.com/nltk/nltk/pull/2860, https://github.com/nltk/nltk_data/pull/165) to incorporate WordNet 3.1 and to bring the WNDB export of the latest Open English Wordnet (OEWN) to the NLTK. These are good and welcome improvements, but render my earlier efforts somewhat unnecessary. In addition, the WordNet 3.1 and OEWN 2021 synset offsets are not compatible with the OMW's tab files, so users must continue to use WordNet 3.0 for them to work. @fcbond would know if it's difficult to re-export the OMW for these newer wordnets, although in the WN-LMF-formatted lexicons we have a version-independent solution: the interlingual index.
So I'd like to know if I should stop working on NLTK-compatibility for the Wn library. Certainly @ekaf's solution is a less disruptive way to bring NLTK users up to speed, at least for English. If so, I think this issue can be closed.

Hi,
I think @ekaf has been working on better reading of the old wordnet
database structure, which is not really being used any more.  Although
there is a script to produce this format for the OEWN, it is not going to
be able to support new information such as the new relations supported by
the OEWN, information about orthographic variants, pronunciation and so
forth.
The vast majority of new wordnets are being produced in some kind of LMF,
with the GWA's format I think being the most supported.  So the Wn library
will support out of the box the German Wordnet, the Uzbeck wordent, and
many others.
So I think that, although sticking with the current code is less
disruptive, it does not allow us to move forward to incorporate more
non-English wordnets, or even take advantage of all the improvements of the
latest and greatest English wordnet.
So I think you should keep working on NLTK-compatibility for the Wn
library, and perhaps we should start discussion of how exactly the
changeover should happen?  We could try to (a) replace the existing module,
or (b) give people a choice of both?  In terms of long term ease of
maintenance, I favor (a).
On Wed, Nov 3, 2021 at 1:20 AM Michael Wayne Goodman <
@.***> wrote:

Hi, returning to this with an update: the Wn library has been, since
shortly after my last comment, documented
https://wn.readthedocs.io/en/latest/ and reasonably feature-complete
since the 0.8.0 release about four months ago. Recently I've been working
on increasing compatibility with the NLTK's wordnet, on two fronts:

A (mostly trivial) Python shim module that implements the NLTK's
API on top of Wn's
Updating the OMW's data
https://github.com/bond-lab/omw-data/pull/16 to fix some regressions
in its export of the WordNet 3.0 data and so we can recreate the NLTK's
synset identifiers (e.g., dog.n.01)

The idea is that these two things would allow it to pass the NLTK's
doctests. I never got a response to my questions above
https://github.com/nltk/nltk/issues/2423#issuecomment-686842825, so I'm
not sure if the goal was to integrate the new system into the NLTK or to
just change the documentation to refer to it. There was some more
discussion at nltk/nltk_data#160
https://github.com/nltk/nltk_data/issues/160.
Meanwhile it seems that @ekaf https://github.com/ekaf has been also
doing good work (#2860 https://github.com/nltk/nltk/pull/2860,
nltk/nltk_data#165 https://github.com/nltk/nltk_data/pull/165) to
incorporate WordNet 3.1 and to bring the WNDB export of the latest Open
English Wordnet (OEWN) to the NLTK. These are good and welcome
improvements, but render my earlier efforts somewhat unnecessary. In
addition, the WordNet 3.1 and OEWN 2021 synset offsets are not compatible
with the OMW's tab files, so users must continue to use WordNet 3.0 for
them to work. @fcbond https://github.com/fcbond would know if it's
difficult to re-export the OMW for these newer wordnets, although in the
WN-LMF-formatted lexicons we have a version-independent solution: the interlingual
index https://github.com/globalwordnet/cili/.
So I'd like to know if I should stop working on NLTK-compatibility for the
Wn library. Certainly @ekaf https://github.com/ekaf's solution is a
less disruptive way to bring NLTK users up to speed, at least for English.
If so, I think this issue can be closed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nltk/nltk/issues/2423#issuecomment-957963659, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIPZRX4NASDE2OD3AUFH3TUKATVBANCNFSM4I444W6Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

Thanks @goodmami for your kind words about my recent updates in the standard wordnet module. It is indeed in better shape now, although the lack of compatibility of OMW with newer Wordnet versions is a shortcoming.
Concerning future plans, a pluralism of approaches is always an advantage and, as @fcbond explains, the new Wn model is very helpful for supporting the LMF format, which NLTK's standard wordnet module doesn't. The combination of ILI and OEWN is certainly promising, and I also look forward to seeing the OMW catching up with the recent Wordnet developments.
On the other hand,  OEWN releases still tend to have much more bugs than Princeton WordNet, so people might still want to have a choice for some time. The standard NLTK wordnet module has much functionality, a large user base, and is still useful until something better comes up.

We could try to (a) replace the existing module, or (b) give people a choice of both?  In terms of long term ease of maintenance, I favor (a).

We could follow what the Python documentation does in similar situations. For instance, urllib.request simply recommends that people use the 3rd-party Requests package, or how the re module recommends the 3rd-party regex package, but the standard library modules are still there. Some reasons for not incorporating these into Python's standard library: slower release cycle for Python, maintenance burden, little gain since they are readily available on PyPI. But adding them to the standard library makes them visible and gives them status as the standard way to do things.
So for Wn and NLTK, maybe the docs could point to Wn for the duration of NLTK's 3.* major version, then for 4.0 we can decide if it's a good idea to make the switch? Waiting for 4.0 wouldn't be necessary if we could guarantee a compatible API, however (or does NLTK not use semantic versioning?).

Concerning the maintenability claim, an important factor is the size of the codebase: the existing wordnet module counts 2301 lines, while the new Wn module is more than triple that size, with 7242 lines, while not feature-complete. Also, who will maintain it? The standard module had many contributors, while future Wn contributions appear less certain.

Hi,
I am not sure comparing numbers of maintainers for a long-lived module vs a
very new one is very meaningful.   I am a contributor to both, and intend
to keep maintaining Wn.  Of course, if it becomes used widely in NLTK then
I would expect more people to help maintain it, ...
But my argument was not that Wn is more maintainable, rather that it is
better to try to only maintain one package not two, and of the two Wn is
more future proof.    People do get value from using the non-English
wordnets, and practically none of them use the old WN db format.   Even
exporting the Open English wordnet to the format is non-trivial (I would go
so far as to say complicated) and I think this will become more difficult
with time, rather than easier, as newer information is added.
BTW, what features do you think are missing in Wn?  I thought it was
feature complete, but that the interface has changed a little, so it is not
a drop in replacement.  A shim to make it work with legacy code is the
missing part, ...      Although of course it does not have the new
graph visualization code you added recently (which looks great BTW).
On Thu, Nov 4, 2021 at 3:06 PM Eric Kafe @.***> wrote:

Concerning the maintenability claim, an important factor is the size of
the codebase: the existing wordnet module counts 2301 lines, while the new
Wn module is more than triple that size, with 7242 lines, while not
feature-complete. Also, who will maintain it? The standard module had many
contributors, while future Wn contributions appear less certain.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nltk/nltk/issues/2423#issuecomment-960506168, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIPZRRUQR7GLJMIYECY3U3UKIWI3ANCNFSM4I444W6Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

Thanks @fcbond. I don't know enough about Wn's features, but I noticed that it doesn't seem to have a "sense key" notion, although sensekeys are the only reliable identifier across Wordnet versions. So I would miss functions like synset_from_sense_key() and lemma_from_key(), which are available in the standard module.
I totally agree that support for LMF is crucial, especially since it is an ISO standard, and many foreign languages are adopting it, although not all yet. But if, as according to http://compling.hss.ntu.edu.sg/omw/, "Wordnet-LMF format files are made by combining the tab files with the Princeton wordnet.", this seems to be just old wine in new bottles, without actually adding anything.
So, before it becomes relevant to replace the NLTK module, it would be nice to see a release of OMW that actually brings all the promised new features into play. Until all this is released and tested, discussions seem highly speculative.

I would be in favor of moving towards a deprecation of the NLTK wordnet module, if Wn is sufficient feature complete to replace core NLTK Wordnet functionality. With some time, and the assistance of the Wn documentation, we might be able to provide detailed deprecation warnings on a function/method level. This way, we can help users move towards using Wn as quickly and smoothly as possible. This also allows us to deprecate the NLTK wordnet module more quickly.
The NLTK wordnet module would still be available upon deprecation for some time, but maintenance on it could be stopped. Similarly to the Stanford Tools, e.g. StanfordTagger (see #2812).
With the deprecated decorator we can provide these per-function deprecation warnings. Concretely, this might look like:
(In nltk/corpus/reader/wordnet.py)
    ...

    #############################################################
    # Retrieve synsets and lemmas.
    #############################################################

    @deprecated('''\
    The NLTK Wordnet module is deprecated.
    It is recommended to use Wn to replace this method.
    For example:
        >>> import wn
        >>> pwn = wn.Wordnet("pwn", "3.0")
        >>> ss = pwn.synsets("chat", pos="v")
    See https://wn.readthedocs.io/en/latest/guides/nltk-migration.html
    for more information.''')
    def synsets(self, lemma, pos=None, lang="eng", check_exceptions=True):
        """Load all synsets with a given lemma and part of speech tag.
        If no pos is specified, all synsets for all parts of speech
        will be loaded.
        If lang is specified, all the synsets associated with the lemma name
        of that language will be returned.
        """
        lemma = lemma.lower()

        ...

Then, when a user executes a file with:
from nltk.corpus import wordnet as wn

...

wn.synsets("chat", pos="v")

The output becomes:
[sic]\nltk_2423.py:2: DeprecationWarning: Function synsets() has been deprecated.
    The NLTK Wordnet module is deprecated.
    It is recommended to use Wn to replace this method.
    For example:
        >>> import wn
        >>> pwn = wn.Wordnet("pwn", "3.0")
        >>> ss = pwn.synsets("chat", pos="v")
    See https://wn.readthedocs.io/en/latest/guides/nltk-migration.html
    for more information.
  wn.synsets("chat", pos="v")

Note that this does not require a 1:1 mapping of functions between NLTK and Wn. If Wn has a different workflow to create the same output, then that is also fine, and can be specified both in the deprecation comment and the documentation. Long story short - I'm trying to avoid simply warning users with "The NLTK Wordnet module is deprecated. Use Wn instead.", as I don't think that will result in proper adoption of Wn by NLTK users.
If we indeed want to go this route, then I would like to perform some small changes to the deprecated decorator:

Expose a flag on the decorator which allows the indentation and newlines of the deprecation message to be preserved. (Currently it's always normalized, I removed that line for the above output)
Allow f-string formatting on variable names to be applied on the deprecation message. In short, a method that has self, lemma, pos=None, lang="eng", check_exceptions=True as the signature can then use a deprecation message like:@deprecated('''\
The NLTK Wordnet module is deprecated.
It is recommended to use Wn to replace this method.
For example:
    >>> import wn
    >>> pwn = wn.Wordnet("pwn", "3.0")
    >>> ss = pwn.synsets({lemma}, pos={pos if pos else "v"}, lang={lang if lang else "eng"})
See https://wn.readthedocs.io/en/latest/guides/nltk-migration.html
for more information.''')

A global and simple way to hide these warnings.

These deprecation changes would likely be easy to implement, so that is not a concern.

Tom Aarsen

https://github.com/globalwordnet/cili/issues/9#issuecomment-929475375 mentions "a backlog of several years" in attributing the envisioned ILI identifiers. This leaves ample time to prepare the deprecation warnings.

it doesn't seem to have a "sense key" notion, although sensekeys are the only reliable identifier across Wordnet versions

This is because sense keys are not a core part of the WN-LMF format. In EWN-2019 and EWN-2020, these were conventionally encoded in the dc:identifier attribute on <Sense> elements, and in OEWN-2021 they are simply the id of those elements, transformed slightly for xsd:id compatibility. The WN-LMF format allows for ili IDs for synsets, which are stable across versions and even across languages, but there is no equivalent mechanism for senses.
In the upcoming OMW 1.4 release we will provide an export of WordNet 3.0 and 3.1 that is more faithful to the source data than the currently distributed one. It will have sense keys, in their original form, as dc:identifier attributes, and it will also encode NLTK-style synset IDs (e.g., entity.n.01) using dc:identifier on <Synset> elements. This will allow the NLTK-compatibility shim to use the synset_from_sense_key() and lemma_from_key() functions, as well as the synset() function, but I still need to test this.

"a backlog of several years" in attributing the envisioned ILI identifiers

That backlog is for new ILIs introduced since the fork from the Princeton WordNet, and currently all the synsets in the OMW wordnets are present in WordNet 3.0, so I don't think that is relevant here. However I'd agree that there's no immediate rush to switch, except for those NLTK users looking for additional features. That is, for those with greater needs, there will be a migration path laid out, while others can continue to use the old module for a while.
@tomaarsen to that point I think the deprecation wording may be a bit strong. Maybe "will be deprecated in version X.Y.Z" instead of "is deprecated", and keep it that way for a version or two so users aren't caught off-guard. Your thoughts on changes to the deprecation message formatting sound good to me.

to that point I think the deprecation wording may be a bit strong. Maybe "will be deprecated in version X.Y.Z" instead of "is deprecated", and keep it that way for a version or two so users aren't caught off-guard. Your thoughts on changes to the deprecation message formatting sound good to me.

The phrasing of the deprecation messages isn't an issue. My example was very much just an example. My main point was to advocate in favour of clear deprecation messages with code snippets. The details of the phrasing can be discussed if we decide to move forward 👍

An update: I've pushed the current state of my NLTK-compatibility shim to Wn in the nltk branch. Here is the relevant file: https://github.com/goodmami/wn/blob/nltk/wn/nltk_api.py
It uses Wn under the hood, but the functions and even class representations mimic the NLTK's. You'll need OMW 1.4:
$ python -m wn download omw:1.4

And here is what it looks like:
>>> from wn import nltk_api as wn
>>> wn.synsets('dog')
[Synset('dog.n.01'), Synset('frump.n.01'), Synset('dog.n.03'), Synset('cad.n.01'), Synset('frank.n.02'), Synset('pawl.n.01'), Synset('andiron.n.01'), Synset('chase.v.01')]
>>> wn.synsets('犬', lang='jpn')
[Synset('dog.n.01'), Synset('spy.n.01')]
>>> wn.lemmas('犬', lang='jpn')
[Lemma('dog.n.01.犬'), Lemma('spy.n.01.犬')]
>>> wn.synsets('犬', lang='jpn')[0].hypernyms()  # works but returns Wn-native synsets
[Synset('omw-en-02083346-n'), Synset('omw-en-01317541-n')]
>>> dog = wn.synsets('dog')[0]
>>> cat = wn.synsets('cat')[0]
>>> wn.path_similarity(dog, cat)
0.2

There are still a number of things unimplemented or partially implemented. If anyone is interested in finishing up the module, I'd be very happy to receive PRs.


Thundercore Hub

There should be a user interface program similar to Facebook to easily view interactions and transactions

Comment


colisions are detected before rendering, need to have a way to draw the colision itself

options:

force render from the game

fixed in 7cef359bd31f73a9a9e9f1ee2ebd9f4250ab8785


Incorrect ExpressionStatement inside ts.Block when using JSX

TypeScript Version:  2.1.4 / nightly (2.2.0-dev.20161223)
Code
import { createSourceFile, ScriptTarget, ExpressionStatement, CallExpression, ArrowFunction, Block } from "typescript";

const sourceFile = `
    it("test", () => {
        // Without JSX (i.e. create()) it works as expected
        let test = create(<Component />);
        expect().func();
    });
`;

const source = createSourceFile("test", sourceFile, ScriptTarget.ES2015, true);
const itExp = source.getChildAt(0).getChildAt(0) as ExpressionStatement;
const arrowFunc = (itExp.expression as CallExpression).arguments[1] as ArrowFunction;
const block = arrowFunc.body as Block;

console.log(block.statements.length);
console.log(block.statements[0].getText());

Expected behavior:
2
let test = create(<Component />)

Actual behavior:
1
let test = create(<Component />);
        expect().func();

My fault, need to use ScriptKind.JSX


Update... Everything? (demos version)

CC https://github.com/jamesmunns/esb/pull/1

whoops, meant to open this on my fork for now.


Add search button in simple filter form

@elador13
Please fix the build for the frontend and the changes will be merged


Add Def1nit3lyN0tAJa1lbr3akTool

I've been using it, relatively stable but still somewhat incomplete (no restore RootFS, no userspace reboot, and SSH is sorta broken)

I've been using it, relatively stable but still somewhat incomplete (no restore RootFS, no userspace reboot, and SSH is sorta broken)

Jailbreak removal functionality is definitely something that's missing, but it's not essential either (palera1n and erasing all content and settings both exist). Userspace Rebooting isn't much of a missing feature considering that ldrestart exists which - while worse - should serve most of the needs that a userspace reboot would.
As for SSH, I'd have to take a look at that, but that's also not something that matters for most end users.


Add streamlined Tag component

Checklist before requesting a review

[x] Working on iOS
[x] Working on Android
[x] Integration tests added
[x] Visual regressions screenshots are up to date
[ ] Design validated

@ianrobertlambert I got issues with the job to generate screenshots but I added the Tag Android screenshot so you can still have a look


Run infection via phpdbg by default, since phpdbg is pre-installed with PHP

Q
A

Documentation
no

Bugfix
yes

BC Break
no

New Feature
no

RFC
no

QA
no

Description
This removes the need for installing pcov or xdebug in environments that need to
run mutation tests: phpdbg being pre-installed means that any bugs with it will
also be reported to the PHP project, instead of dragging in bugs from third-party
extensions.
This also fixes builds for projects that did not declare ext-pcov or ext-xdebug
as dependencies in require-dev: no need to have those, when running this task.

As discussed with @boesing, will need to adjust laminas-continuous-integration-action too - investigating/preparing a patch


[Progress]  Jericho Player v2 for discord.js v14 , @discordjs/voice and discord Api v10 Support

(Jericho Player v2 Project has been opened)[https://github.com/SidisLiveYT/Jericho-Player/projects/1]

v1.2.x supports discord.js v14 from now onwards and we are dropping discord.js v13 support


Refreshing the screen (fragment) from another thread

Hi,
I am using Otto on my application. It works well.
I would be interested in refreshing the screen from an event in an intentservice (which has its own thread).
For that, I am trying to use Otto with ThreadEnforcer.ANY
But I got the same exception that I would obtain if I would call the view directly from the intentService (means other that the main thread). Is there a way in Otto to "redirect" easily the event from the IntentService to the Main thread ??? I just want to know when to do it.
Thank you
Michael

Looks just perfect.
What are the drawbacks of such a pattern?
Are there better alternative to propagate a model change in a service back to the ui?
F.

Lets pretend you have directly used Bus everywhere already, you can use composition over inheritance.
public class BusUtil
{
private static final Handler mainThread = new Handler(Looper.getMainLooper());
public static void postOnMain( final Bus bus, final Object event) {

    mainThread.post(new Runnable() {
        @Override
        public void run() {
            bus.post(event);
        }
    });
}

}

what is a best approach to handle event parameter in case is null? - return from the method in case is null or creating new object instead?


Python 3.70b1 added!

Python 3.70b1 is added.
Installation is working but not sure for autoupdating. Any correction are welcomed!

Since we have packages named python27 and python3 (python), I think this package should be named simply python-beta, as a beta of the python27 package would be named python27-beta. Agreed? There will never multiple 3.x betas.

Also, the checkver needs to be changed to something like (untested):
"checkver": {
  "url": "https://www.python.org/downloads/windows/",
  "re": "/downloads/release/python-3[^\"]*\">Python\s*([\\da-z.]+)"
}

@rasa thx for your comments and contributions for this project. this is my first time adding software to buckets. i simply copy paste python file and change accordingly to beta. i will change name immediately. i don't want to change chekver part until new version of beta is coming.

You either need to add the checkver (preferred) or remove the autoupdate, because the two work together, and you have the wrong checkver for the 3.7 beta branch

@rasa as i said this is my first time creating app manifest. (actually im not even created it im just edited it.) if i have chance (you guys are really fast) to add other apps to repo, i will be more carefull. thx for your warnings.
@r15ch13 thx for cleaning my mess... 🥂


250 Message limit from the service

Hey mate,
once again, thank you very much for the powershell cmdlet, it really comes handy as at the moment i haven't found any other way to retrieve messages from the deadletter queue of a service bus
Are you aware, or is it just me, that I can only receive a maximum of 250 messages?

Hey @ejike-nnodi - no problem. As you can see it has been a while since I've looked at this module... could you show me the command(s) you're using to repro this issue?

I completely understand.. actually thank you so much for reading me @tmeadon ,
i am using this command:
Receive-SbMessagesInBatch -NamespaceConnectionString $NamespaceConnectionString -QueueName $queueName -ReceiveQty 9999 -ReceiveFromDeadLetterQueue > test.json
When doing this even though my queue has more than 1.5k messages, it only returns a maximum of 250


Adding New-CsTeamsFeedbackPolicy

https://github.com/MicrosoftDocs/office-docs-powershell/issues/5364

Docs Build status updates of commit 2b6adc3:
:clock10: Full build: the average full build time is 13 min(s) 43 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit 2b6adc3:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

skype/skype-ps/skype/New-CsTeamsFeedbackPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 002a8df:
:clock10: Full build: the average full build time is 13 min(s) 46 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit 002a8df:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

skype/skype-ps/skype/New-CsTeamsFeedbackPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


python312Packages.pypdf: 4.2.0 -> 4.3.1

Description of changes
https://github.com/py-pdf/pypdf/releases/tag/4.3.1

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

Is the comicon update supposed to be here?

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

8 packages marked as broken and skipped:

python311Packages.llama-index
python311Packages.llama-index-readers-file
python311Packages.llama-index-readers-file.dist
python311Packages.llama-index-readers-s3
python311Packages.llama-index-readers-s3.dist
python311Packages.llama-index.dist
python311Packages.private-gpt
python311Packages.private-gpt.dist

60 packages built:

alpaca
calibre-web
calibre-web.dist
cewler
cewler.dist
comic-mandown
comic-mandown.dist
diffoscope
diffoscope.dist
diffoscope.man
diffoscopeMinimal
diffoscopeMinimal.dist
diffoscopeMinimal.man
mdbook-pdf-outline
mdbook-pdf-outline.dist
open-webui
open-webui.dist
pretix
pretix.dist
python311Packages.camelot
python311Packages.camelot.dist
python311Packages.comicon
python311Packages.comicon.dist
python311Packages.fpdf2
python311Packages.fpdf2.dist
python311Packages.mandown
python311Packages.mandown.dist
python311Packages.pypdf
python311Packages.pypdf.dist
python311Packages.pypdf.doc
python311Packages.xhtml2pdf
python311Packages.xhtml2pdf.dist
python312Packages.camelot
python312Packages.camelot.dist
python312Packages.comicon
python312Packages.comicon.dist
python312Packages.fpdf2
python312Packages.fpdf2.dist
python312Packages.mandown
python312Packages.mandown.dist
python312Packages.pypdf
python312Packages.pypdf.dist
python312Packages.pypdf.doc
tests.dotnet.structured-attrs.check-output
tests.dotnet.use-dotnet-from-env.fallback
tests.dotnet.use-dotnet-from-env.use-dotnet-path-env
tests.dotnet.use-dotnet-from-env.use-dotnet-root-env
tests.substitute.legacySingleArg
tests.substitute.legacySingleReplace
tests.substitute.legacyString
tests.substitute.legacyVar
tests.substitute.substitutions
tests.testers.testEqualContents.emptyFileAndDir
tests.testers.testEqualContents.equalDir
tests.testers.testEqualContents.equalExe
tests.testers.testEqualContents.fileDiff
tests.testers.testEqualContents.fileMissing
tests.testers.testEqualContents.nonExistentPath
tests.testers.testEqualContents.unequalExe
tests.testers.testEqualContents.unequalExeInDir


(win7) Linking ws2_32

Using MinGW it works fine.
Using VisualStudio it can't find it.
In enet\SCSub
MinGW requires env.Append(LIBS=['ws2_32'])
VisualStudio requires env.Append(LINKFLAGS=["ws2_32.lib"]) instead of it

Does it still work with MinGW after the change? I don't have time to do a lot of testing these days.

If LINKFLAGS is a list add both. is posible?

@jrimclean No, it doesn't. I think the best way would be to check which one is used to compile and then use the correct line, but I don't know how to check this.

@Kermer Godot's build system is rather murky and I'm not an expert with SCons, but I'll see if there's a variable that reveals which compiler is being used. I should be able to do some work this weekend. I hope this isn't urgent?
@rdcklinux It might be possible to add one library to LIBS and one to LINKFLAGS, but the linker will probably complain that it can't find the file.

@Kermer It would help if you could give me a brief description of how you setup your project in VS and which version you're using.

@Kermer I found something that might be useful: http://stackoverflow.com/questions/1961164/how-can-i-set-options-in-sconstruct-for-c-compiler-depending-on-compiler-type

if (env['platform'] == 'windows'):
	if (env['CC'] == 'cl'):
		env.Append(LINKFLAGS=["ws2_32.lib"])
	else: # gcc mostly
		env.Append(LIBS=['ws2_32'])

This should fix it


Support using PR title instead of commit heading when generating changelogs and release notes

Is your feature request related to a problem? Please describe.
In our repository, we enabled automated dependency updates using tools such as Dependabot and Renovate Bot. These tools create PRs with titles that have details about the versions of dependencies being updated. The heading of commit messages in those PRs are shorter to (try to) make them compliant with the Conventional Commits spec when they might overflow a certain length.
As release-please pulls the commit title to write it in the changelog and in release-notes, it might obfuscate the version information.
Example:
PR title: deps(docker): bump dotnet/sdk from 8.0.302-alpine3.20 to 8.0.303-alpine3.20
Commit heading: deps(docker): bump dotnet/sdk
Commit description:
Bumps dotnet/sdk from 8.0.302-alpine3.20 to 8.0.303-alpine3.20.

---
updated-dependencies:
- dependency-name: dotnet/sdk
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot]<EMAIL_ADDRESS>
Resulting changelog and release notes line: docker: bump dotnet/sdk (link to PR) (link to commit)
Describe the solution you'd like
A configurable option to use the PR title instead of the commit heading to generate the changelog and the release notes.
Desired changelog and release notes line: deps(docker): bump dotnet/sdk from 8.0.302-alpine3.20 to 8.0.303-alpine3.20 (link to PR) (link to commit)
Describe alternatives you've considered
Manually rewriting release notes might be an option, although it doesn't scale.
Additional context
Nothing for now.
Thanks for your support!

@ferrarimarco change your github settings so that squash merge commit title is PR title

Hi @kevcube ! We don't have too much control over PR titles because they are automatically generated by dependabot.


refactor(backend): change image field of book

related issue #18
changed the image field to store url
created a bucket in aws to store images
refactored book controller and service accordingly


Certificate Transparency Tests

In particular, for this change I could use test cases for invalid and unrecognized SCTs.

From this Chromium CL, here are existing examples:

DV, no SCT: https://garron.net/
DV, SCT: https://embed.ct.digicert.com/
EV, no SCT: https://www.mozilla.org/
EV, SCT: https://www.bankofamerica.com/

Note: we are already preloaded for expect-ct as a test.

For some changes that I'm working on, I could use:

Invalid SCTs.
SCTs from unknown (bogus) logs.


Integrated to DAB RBAC role and permission models

UNFINISHED:

Migrate role assignments from old system to new system, this is needed to preserve pre-migration permissions
create_initial_data integration is needed to create roles like "Admin" in a new system. Currently these are migrated in the role data migration, which means that new installs do not get those roles.

I'm going to talk out my next steps in a little bit of detail, mostly to help myself
Migrating assignments
This got a little ugly in AWX, because I made the decision to duplicate ObjectRole fields onto the assignment models (like RoleUserAssignment). So I want to move that little blurb into a migration utils method in DAB RBAC. Then I can test AWX again to be sure that it's working. Then I would import and use that method here for migrating permissions.
I can manually test permission migrations. Run server with the base branch, set up permissions, then switch to new branch and run again. I would like to get some automation around this, but manual might be what I need for the next ~1 day
Changes to role migration
There are many places where roles can be created. Various things done before:

Creating roles inside of a RunPython data migration
Creating roles in the post_migrate Django signal (what DAB RBAC does)
Creating roles with a management command, specifically the create_initial_data here

Right now I have stuff that migrates existing roles with (1). Need to run logic in (3), the existing create_initial_data command basically. I turned on the setting for DAB RBAC to create some managed roles at (2), but I will turn this off, because I don't think it will fit the aesthetic we want.
In terms of work items, this practically means:

disabling the DAB managed role auto-creation
adjusting the create_initial_data command to create the new-style roles
add additional logic in create_initial_data to create object roles, perhaps partly copied over from DAB RBAC

I've been back-and-fourth about the migration step at (1), and whether we need that. I think we do, for the scenario that someone ran create_initial_data and then migrated. We need to migrate those roles, but new installs will use the management command to create roles. So I'm saying we need both forms of creation of the new RoleDefinition.

With this, I've put in some minimal support for backward-compatibility, just because I didn't know what else to do. So I'll show the differences here.
Role List View
at /api/eda/v1/roles/

Before these changes
{
    "count": 6,
    "next": null,
    "previous": null,
    "page_size": 20,
    "page": 1,
    "results": [
        {
            "id": "0eb51dc8-7ee7-4ffc-a9eb-0d4d84a94970",
            "name": "Editor",
            "description": "Has create and edit permissions."
        },
        {
            "id": "36abb085-f8bf-400a-9493-3eea9f55b542",
            "name": "Contributor",
            "description": "Has create and update permissions with an exception of users and roles. Has enable and disable rulebook activation permissions."
        },
        {
            "id": "a0a4eb07-c4a5-45d9-84b2-75996ac775a2",
            "name": "Auditor",
            "description": "Has all read permissions."
        },
        {
            "id": "a55bd198-f680-4ce0-9a72-b65c44f0fb5a",
            "name": "Admin",
            "description": "Has all permissions"
        },
        {
            "id": "c595ec48-3ebc-4ec6-886f-8ecea37e4e1d",
            "name": "Operator",
            "description": "Has read permissions. Has permissions to enable and disable rulebook activations."
        },
        {
            "id": "e3c0dba2-072c-45fb-a4e1-52711b841066",
            "name": "Viewer",
            "description": "Has read permissions, except users and roles."
        }
    ]
}

After these changes
{
    "count": 18,
    "next": null,
    "previous": null,
    "page_size": 20,
    "page": 1,
    "results": [
        {
            "id": 29,
            "name": "Admin",
            "description": "Has all permissions"
        },
        {
            "id": 30,
            "name": "Editor",
            "description": "Has create and edit permissions."
        },
        {
            "id": 31,
            "name": "Contributor",
            "description": "Has create and update permissions with an exception of users and roles. Has enable and disable rulebook activation permissions."
        },
        {
            "id": 32,
            "name": "Operator",
            "description": "Has read permissions. Has permissions to enable and disable rulebook activations."
        },
        {
            "id": 33,
            "name": "Auditor",
            "description": "Has all read permissions."
        },
        {
            "id": 34,
            "name": "Viewer",
            "description": "Has read permissions, except users and roles."
        },
        {
            "id": 35,
            "name": "Credential Admin",
            "description": "Has all permissions to a single credential"
        },
        {
            "id": 36,
            "name": "Audit Event Admin",
            "description": "Has all permissions to a single audit event"
        },
        {
            "id": 37,
            "name": "Decision Environment Admin",
            "description": "Has all permissions to a single decision environment"
        },
        {
            "id": 38,
            "name": "Organization Admin",
            "description": "Has all permissions to a single organization"
        },
        {
            "id": 39,
            "name": "Project Admin",
            "description": "Has all permissions to a single project"
        },
        {
            "id": 40,
            "name": "Event Stream Admin",
            "description": "Has all permissions to a single event stream"
        },
        {
            "id": 41,
            "name": "Extra Var Admin",
            "description": "Has all permissions to a single extra var"
        },
        {
            "id": 42,
            "name": "Rulebook Process Admin",
            "description": "Has all permissions to a single rulebook process"
        },
        {
            "id": 43,
            "name": "Team Admin",
            "description": "Has all permissions to a single team"
        },
        {
            "id": 44,
            "name": "Audit Rule Admin",
            "description": "Has all permissions to a single audit rule"
        },
        {
            "id": 45,
            "name": "Activation Admin",
            "description": "Has all permissions to a single activation"
        },
        {
            "id": 46,
            "name": "Rulebook Admin",
            "description": "Has all permissions to a single rulebook"
        }
    ]
}

Role Detail View
at /api/eda/v1/roles/29/

Before these changes

{
    "id": "a55bd198-f680-4ce0-9a72-b65c44f0fb5a",
    "name": "Admin",
    "description": "Has all permissions",
    "permissions": [
        {
            "resource_type": "activation",
            "action": [
                "create",
                "read",
                "update",
                "delete",
                "enable",
                "disable",
                "restart"
            ]
        },
        {
            "resource_type": "activation_instance",
            "action": [
                "read",
                "delete"
            ]
        },
        {
            "resource_type": "audit_rule",
            "action": [
                "read"
            ]
        },
        {
            "resource_type": "audit_event",
            "action": [
                "read"
            ]
        },
        {
            "resource_type": "task",
            "action": [
                "read"
            ]
        },

Some data truncated...

After these changes
{
    "id": 29,
    "name": "Admin",
    "description": "Has all permissions",
    "permissions": [
        {
            "resource_type": "activation",
            "action": [
                "add",
                "change",
                "delete",
                "disable",
                "enable",
                "restart",
                "view"
            ]
        },
        {
            "resource_type": "auditevent",
            "action": [
                "view"
            ]
        },
        {
            "resource_type": "auditrule",
            "action": [
                "view"
            ]
        },
        {
            "resource_type": "credential",
            "action": [
                "add",
                "change",
                "delete",
                "view"
            ]
        },
        {
            "resource_type": "decisionenvironment",
            "action": [
                "add",
                "change",
                "delete",
                "view"
            ]
        },
        {
            "resource_type": "eventstream",
            "action": [
                "add",
                "view"
            ]
        },
        {
            "resource_type": "extravar",
            "action": [
                "add",
                "change",
                "delete",
                "view"
            ]
        },
        {
            "resource_type": "organization",
            "action": [
                "change",
                "delete",
                "view"
            ]
        },
        {
            "resource_type": "project",
            "action": [
                "add",
                "change",
                "delete",
                "view"
            ]
        },
        {
            "resource_type": "rulebook",
            "action": [
                "add",
                "change",
                "delete",
                "view"
            ]
        },
        {
            "resource_type": "rulebookprocess",
            "action": [
                "delete",
                "view"
            ]
        },
        {
            "resource_type": "team",
            "action": [
                "add",
                "change",
                "delete",
                "member",
                "view"
            ]
        }
    ],
    "created_at": "2024-02-16T19:15:49.832302Z",
    "modified_at": "2024-02-16T19:15:49.832302Z"
}

Note that some permission names have changed here. The migrated role names should be the same. This is intentional, and I don't really want to reverse it.
We do not want people to use this views, the new view is at /api/eda/v1/role_definitions/


New stricter ESLint rules. sorry ;)

This is great, I would like I said before also appreciate code review on github to be part of the process.

Do you have a particular example of what you're looking for in a review?
On Oct 6, 2017 01:24, "Martin Zackrisson"<EMAIL_ADDRESS>wrote:

This is great, I would like I said before also appreciate code review on
github to be part of the process.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ludumdare/ludumdare/pull/1249#issuecomment-334661344,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABf2CWaGOyEiIMr_rHbRagIs3L_LOCsrks5spbmDgaJpZM4Pv2jb
.

I hade used className rather than class.  As an example and I might very well not have looked at you fix.
But also in general, though it requires more of the person doing the pr, it is also a way to teach each other and learn. even if frustrating at times.
I am also thinking that if review was more of a thing it would spread the responsibly a bit even if you have the final check/say so.

Okay, I think I get it. So it's more a request for a report after talking about what and why I changed things, and highlighting things to watch out for.
Is it fine that I do it right in the closed/merged PR? Like this one, because we're both talking, we're both getting replies sent to us. Let me go give an example...

I get all notifications for all things on LD, so for me it is fine. In general it should notify the person who did the PR, so yes. I think that is fine. And to be clear, it is just a suggestion

It's a good suggestion. :+1:


*Chart and DataSeries standardization

tl;dr: we need to choose a single format for creating Charts and their elements via the DataSeries.
Currently, *Charts and their respective DataSeries are implemented one of two ways:

The *Chart creates a dataSeriesArray by mapping over the data. Each DataSeries produces one chart element, such as a single line (with its circles) in LineChart

Ex. from LineChart:
...
render() {
    var dataSeriesArray = data.map( (series, idx) => {
        return (
            <DataSeries
              key={idx}
              structure={structure}
              xScale={scales.xScale}
              yScale={scales.yScale}
              seriesName={series.name}
              data={series.values}
              width={innerWidth}
              height={innerHeight}
              fill={props.colors(props.colorAccessor(series, idx))}
              circleRadius={props.circleRadius}
              xAccessor={props.xAccessor}
              yAccessor={props.yAccessor}
              interpolationType={interpolationType}
              displayDataPoints={props.displayDataPoints}
            />
        );
    });

    return (
        <Chart
            ...
        >
            <g
                {dataSeriesArray}
            >
            ...
        </Chart>
    );
}

The *Chart has a DataSeries element which creates all the chart elements. The single DataSeries creates all the elements by mapping over them, such as all the bars in BarChart.

Ex. from BarChart:
...
render() {
    return (
        <Chart
            viewBox={props.viewBox}
            legend={props.legend}
            data={props.data}
            margins={props.margins}
            colors={props.colors}
            colorAccessor={props.colorAccessor}
            width={props.width}
            height={props.height}
            title={props.title}
        >
            <g transform={trans} className='rd3-barchart'>
                <DataSeries
                    values={values}
                    labels={labels}
                    yScale={yScale}
                    xScale={yScale}
                    margins={margins}
                    data={props.data}
                    width={props.width - sideMargins}
                    height={props.height - topBottomMargins}
                    colors={props.colors}
                    colorAccessor={props.colorAccessor}
                    hoverAnimation={props.hoverAnimation}
                />
                ...
            </g>
        </Chart>
     );
}

We should chose one way of doing things to be standard. This will allow for much simpler code reading, more generic code plugins such as through Mixins, and easier maintenance.
Personally, I prefer the first option. To me, each DataSeries should infer a single series of data such as a line or a bar, rather than all of the series of data.
@esbullington @yang-wei

It's true that we are doing this in 2 ways. As you know our graphs are categorized into 2 types

multi-series chart
single-series chart

IMO sharable code between these 2 series do not seems that much for me.

each DataSeries should infer a single series of data such as a line or a bar,

In our BarChart, we only have single series and they are rendering rect element only. So I think it's ok to keep in this way. In future when we need to support multi series BarChart, then we should do it in the way LineChart doing.
Sorry for the late reply @MatthewHerbst .

@yang-wei imho: the way our barchart is implemented right now, it can be trivially used as a multi-series chart, where each series simply has a single data point (each bar is then its own series).
I think all charts should be expressed as multi-series charts. If the user only puts a single series onto them, that is their choice.
As an example of where code differs, the way props.colors and props.colorAccessor is implemented to create the fill for LineChart and BarChart varies, since in one you pass the fill directly to the DataSeries, while in the other, you pass the two props themselves. This not only affects maintenance, but also affects things such as which class needs to have default props for required props and so on.

it can be trivially used as a multi-series chart,

You get me right ! Let's do this. So the charts we need to refactor are

[ ] BarChart
[ ] PieChart
[ ] Treemap

I realized that it's not that easy to do it for all the charts especially scatterchart and linechart.
As you can see in my latest pr for linechart. Our approach now is to flat all data into a new data and map over it to generate voronoi and respective svg component(rect, circle etc). To do this, the second option you showed above is way more easier.
If you have a greater approach of my latest pr do let me know.

Why is it easier? I think the only main difference between the two ways is which component you do that map in. I think the first way is more expressive of what is actually going on. The second way hides that the DataSeries is doing much more than just operating on a single DataSeries.
Maybe you can explain it better to me, but I really don't understand why we need any of the voronoi stuff. Why are event handlers that simply call this.setState({things you want to change for animation}) not good enough?

but I really don't understand why we need any of the voronoi stuff.

If we get rid of voronoi surely it would be easier.  Voronoi is needed to do better animation in graph like scatter chart etc. Looks at the examples of scatter chart in react-d3-component. You'd have to hover on the top of circle to trigger tooltip. Voronoi helps to create greater experience.
By implementing voronoi, we need to rely it to handler our events(click etc). So our multiple series graph data have to be flatted. We probably won't dump voronoi.

What's so bad about having to hover over the circle? I'm not sure there is a better way to do it - if you are showing all data points in the y-axis when hovering, what happens if I drop 1,000+ elements into the graph? That's not unreasonable depending on what the chart is showing.
imho, we should dump animation, unless we want to implement d3.transition()

So I've decided to go with the second option where we only have one DataSeries. Maybe DataSeries is not the correct name in this case but I think it's fine for now since it's not exposed as our API.
Also for future reference, I write out what is the job of each layer. Our charts are not 100% as stated in below but as you say let's make a standard.

Component
What they do

ChartName
User input, manipulate data and pass to DataSeries, Axes, Chart etc

Chart
Graph with or without legend, legend styling etc

Data Series
Apply d3 function (such as voronoi, layout.treemap ) and pass to container via mapping etc

Container
Managing state for animation and pass prop to children

SVG Component
Should be stateless, can be reused via other charts

One thing I don't understand is the need for containers - why can't say, a Circle, just animate itself?

@MatthewHerbst This article explains well =)

:+1:

Close due to inactive. Please open a new issue to make further discussion.


Putting dialog trigger inside dropdown menu adds an extra div

Describe the bug
I wan't to use a dialog and put it's trigger inside a dropdown menu, the issue I'm having is that it messes up the look since it adds an extra div that wasn't there before.
Here's how it looks when not using the dropdown component:

It behaves as expected with no problem, but when I instead try to use the dropdown menu this happens:

Now there is sudenly an extra div right after the trigger button and this messes up the look of the links.
Here's the code of the dropdown menu:

<DropdownMenu.Root>
	<DropdownMenu.Trigger asChild let:builder>
		<Button builders={[builder]} variant="outline">Open</Button>
	</DropdownMenu.Trigger>
	<DropdownMenu.Content
		class="p-6 2xs:px-10 text-center flex flex-col gap-4 bg-black bg-opacity-90"
	>
		<NavLinks />
	</DropdownMenu.Content>
</DropdownMenu.Root>

And this is is the code in the NavLinks component:
 Nosotros
 Servicios
 Soporte
 Clientes
<Contact>
	<button class="link">Contacto</button>
</Contact>
 Tienda en Línea

It's just a couple of a tags, I need to do it this way because I use those tags somewhere else with a different format.
Reproduction
You can just copy and paste the code I provided in the description
Logs
No response
System Info
System:
    OS: Linux 5.15 openSUSE Tumbleweed 20240305
    CPU: (12) x64 AMD Ryzen 5 Microsoft Surface (R) Edition
    Memory: 3.73 GB / 7.49 GB
    Container: Yes
    Shell: 3.6.0 - /usr/bin/fish
  Binaries:
    Node: 21.7.1 - ~/.local/share/nvm/v21.7.1/bin/node
    Yarn: 1.22.19 - /mnt/c/Users/Chris/AppData/Roaming/npm/yarn
    npm: 10.5.0 - ~/.local/share/nvm/v21.7.1/bin/npm
    pnpm: 8.15.4 - ~/.local/share/pnpm/pnpm
  npmPackages:
    @sveltejs/kit: ^2.0.0 => 2.5.2
    bits-ui: ^0.19.5 => 0.19.5
    svelte: ^4.2.7 => 4.2.12

Severity
annoyance

Hi @ChrisPoul
I also ran into a problem when calling a Dialog from within a Dropdown menu. It's mentioned a lot on the original Shadcn repo (the ui.shadcn.com) and people suggest different ideas over there that you can probably translate here. This uses the same basic ideas after all.
It sounds like your issue may be solved by what I did: open the Dialog programatically using a standard Dropdown.Item element. That way the Dialog is not "in" the Dropdown menu. It's a sibling of it. So it won't add any div etc. which may be breaking your layout.
The idea is essentially this (in my case, it's an AlertDialog rather than a Dialog, but the same idea applies).
<DropdownMenu.Root>
	<DropdownMenu.Trigger asChild let:builder>
		<Button variant="ghost" builders={[builder]} class="relative h-8 w-8 p-0">
			Open menu
			<Icons.DotsHorizontal class="h-4 w-4" />
		</Button>
	</DropdownMenu.Trigger>
	<DropdownMenu.Content>
		<DropdownMenu.Item href="/example">Example</DropdownMenu.Item>
		<DropdownMenu.Item on:click={openDialog(exampleParam)}>Open dialog</DropdownMenu.Item>
	</DropdownMenu.Content>
</DropdownMenu.Root>

Notice that rather than have a Dialog with a Trigger component, there is an on:click instead. Now the Dialog does not need a Trigger component. So you can put the Dialog as a sibling, below it, and so its HTML can't affect the Dropdown HTML e.g
<AlertDialog.Root open={dialogOpen} onOpenChange={(open) => (dialogOpen = open)}>
	<AlertDialog.Content>
		<AlertDialog.Header>
			<AlertDialog.Title>Example</AlertDialog.Title>
			<AlertDialog.Description>Are you sure?</AlertDialog.Description>
		</AlertDialog.Header>
		<AlertDialog.Footer>
			<AlertDialog.Cancel>No</AlertDialog.Cancel>
		</AlertDialog.Footer>
	</AlertDialog.Content>
</AlertDialog.Root>

Note that since the Dialog is now being opened with an on:click you will need to keep track of its opened state with a boolean. Why? Well ... if someone opens the Dialog with a click on the Dropdown ... but then closes it by pressing Escape ... your UI is then out of sync. Hence the dialogOpen which is set as true within dialogOpen(...).

Thank you for your help @gregmsanderson, this solved my issue

Very helpful, @gregmsanderson!
I think you could do <AlertDialog.Root bind:open={dialogOpen}> and let the two-way binding take care of keeping dialogOpen in sync :)

@Stadly No problem. You may well be right about that.


[#3187] feat(spark-connector): Support SparkSQL extended syntax in Iceberg

What changes were proposed in this pull request?
Support SparkSQL extended syntax in Iceberg, such as:
addPartitionField
dropPartitionField
replacePartitionField
setWriteDistributionAndOrdering
setIdentifierFields
dropIdentifierFields
createOrReplaceBranch
createOrReplaceTag
dropBranch
dropTag

Why are the changes needed?
Support SparkSQL extended syntax in Iceberg.
Fix:  https://github.com/datastrato/gravitino/issues/3187
Does this PR introduce any user-facing change?
No.
How was this patch tested?
New ITs.

Hi @FANNG1 could you please help review this pr first if you are free? I am trying to find a solution to fix the issue of metadata tables.

Hi @FANNG1 could you please help review this pr first if you are free? I am trying to find a solution to fix the issue of metadata tables.

ok, but I will take some time to review this PR, and my main concern about this PR is the multi Spark version compatibility.

Hi @FANNG1 could you please help review this pr first if you are free? I am trying to find a solution to fix the issue of metadata tables.

ok, but I will take some time to review this PR, and my main concern about this PR is the multi Spark version compatibility.

ok.

@caican00  could you rebase the code when you are free, thanks

@caican00 could you rebase the code when you are free, thanks

ok

Hi @FANNG1 could you help re-trigger the pipeline because doris container startup failed

Hi @FANNG1 could you help re-trigger the pipeline because doris container startup failed

done

@FANNG1 ready for review, thanks!

@jerryshao @qqqttt123 do you have time to review this PR?

Hi @FANNG1 could you help review this again? thank you!

LGTM, except one comment

LGTM, except one comment

comment has been addressed. cc @FANNG1

LGTM

@caican00  merged to the main, thanks for your work


[System Tests]: DCOS-12811: Add SI tests for pod with ephemeral volume

This PR introduces the automated tests for Create a pod with a virtual network
The following test is expected to fail, because some volume labels have changed (MiB to GiB, or vice versa, I can't remember) and they have not yet been released in the DCOS release branches:
✘ Services Applications Create an app with external volume

To run this test use:

docker pull mesosphere/dcos-ui && docker run -it --rm --ipc=host \
  -e CLUSTER_URL=$CLUSTER_URL  \
  -v `pwd`:/dcos-ui \
  mesosphere/dcos-ui dcos-system-test-driver \
  ./system-tests/driver-config/cluster.sh

Flicts.

Rebased @Poltergeist
Ping @MatApple @wavesoft

Sorry to be obnoxious! Ping @MatApple @wavesoft

@jfurrow same comment for this PR as here :) https://github.com/dcos/dcos-ui/pull/2040#issuecomment-295893797

run integration tests

Sorry @jfurrow more conflicts! My fault for not reviewing fast enough :-(

I rebased your branch :)


ImportError: No module named pgoapi.exceptions

Curtiss-MacBook-Pro:PokemonGo-Bot curtismcintyre$ python pokecli.py --config ./configs/config.json
Traceback (most recent call last):
File "pokecli.py", line 38, in
from pgoapi.exceptions import NotLoggedInException, ServerSideRequestThrottlingException, ServerBusyOrOfflineException
ImportError: No module named pgoapi.exceptions
How to Fix this?

hey i had the same error and i fixed it by writing pip install -r requirements.txt , hope this helps !

Hi, maybe you forgot to run the first line :
$ source bin/activate
$ python pokecli.py
When I do not source the bin/activate file I have the same error

In this particular case, pip install -r requirements.txt will install all listed package versions to the exact specified version. Most of them work just fine as pip should behave, as they are managed packages of the pypi. The exception here is the pgoapi package, listed on line 3. It is not a pypi package. It is a github repository. Pip handle it badly. In occasions you have to remove the whole repository cloned by pip (rm -rf pgoapi) and do pip install again, i.e. pip install -r requirements.txt
This is a great opportunity to learn python!


Fix nucleo flash support

Some nucleo boards were missing config files for openocd support.
Fix this and update doc
Fixes #5766

Codecov Report

Merging #6057 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #6057   +/-   ##
=======================================
  Coverage   52.63%   52.63%
=======================================
  Files         410      410
  Lines       40041    40041
  Branches     7779     7779
=======================================
  Hits        21074    21074
  Misses      15767    15767
  Partials     3200     3200

Continue to review full report at Codecov.

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


rm tests

Codecov Report

Merging #13 into master will decrease coverage by 1.18%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master     #13      +/-   ##
=========================================
- Coverage   97.89%   96.7%   -1.19%
=========================================
  Files          27      26       -1
  Lines         808     759      -49
=========================================
- Hits          791     734      -57
- Misses         17      25       +8

Impacted Files
Coverage Δ

accounts/views.py
66.66% <0%> (-33.34%)
:arrow_down:

Continue to review full report at Codecov.

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

Pull Request Test Coverage Report for Build 33

0 of 0   changed or added relevant lines in 0 files are covered.
8 unchanged lines in 1 file lost coverage.


Apache Pulsar Scaler

Added Apache Pulsar Scaler code
Checklist

[X] Commits are signed with Developer Certificate of Origin (DCO - learn more)
[X] Tests have been added
~[ ] A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)~
[x] A PR is opened to update the documentation on (repo) (if applicable)
[X] Changelog has been updated

Relates to #853

@mmussett any update on this?

@zroubalik I'll be back on it soon, work got in the way 😄

@zroubalik I'll be back on it soon, work got in the way 😄

No worries and no rush, I know this very well 😄
FYI the next release won't happen in the next few weeks, so you have a plenty of time (in case you'd like to have this in that release).

Any update on this @mmussett ?

Any update on this @mmussett  ?

@mmussett Did you get some time to work towards finishing this up? I would be grateful if this is pushed through when you can. Thanks.

Any update on this?

I think it's fair to say that @mmussett will probably not close this soon. If somebody wants to continue his work, feel free to let me know and I'll merge it in a temp branch for you to use.

Guys, this would be an awesome and much needed feature. Please make it available ASAP

We are open to contributions. Do you want to extend this PR?

Feel free to let me know  @sanketrk

Closing due to inactivity, feel free to ping us if someone wants to pick it up.


Bug OCPBUGS-1159: Fix treating missing clusters in policy compliance status as compliant

Now checks specifically if the cluster is compliant with policy and don't consider missing clusters as compliant.
Signed-off-by: Saeid Askari<EMAIL_ADDRESS>

/jira refresh

/jira-refresh

/jira refresh

/jira refresh

/jira refresh


How to profile engine using trtexec

When I use trtexec to profile engine using command
trtexec --loadEngine=<llm.engine> --dynamicPlugins=TensorRT-LLM/cpp/build/tensorrt_llm/plugins/libnvinfer_plugin_tensorrt_llm.so

I got coredump error

I'm sad I cannot download any file including nsys, ncu profile file from the server. So I can only use the profiler like trtexec or nvprof. Also be glad for providing me with other suggestions for performance analysis.

If you use the docker image by following the doc , the nsys/ncu are shipped with that container.
You don't need to download nsys/ncu any more.

If you use the docker image by following the doc , the nsys/ncu are shipped with that container. You don't need to download nsys/ncu any more.

I mean I cannot download the profiling  output file like nsys-rep from server to local pc, where download behavior is blocked.

@haojiwei
Sorry, but it is suggested to use nsys/ncu to do the profiling for TensorRT-LLM.
June

@haojiwei Sorry, but it is suggested to use nsys/ncu to do the profiling for TensorRT-LLM.
June

I wonder what causes the segfault

Could try real shapes by trtexec  --shapes=... based on your bs and sequence length? Otherwise, the dynamic shape will be set 1 as default.

Could try real shapes by trtexec --shapes=... based on your bs and sequence length? Otherwise, the dynamic shape will be set 1 as default.

I profile for the LLamaForCausalLM, and tried
--shapes=input_ids:1x1 --exportProfile=./profile.json --exportOutput=./output.json --exportTimes=./times.json.
There is no more output after starting inference and none of ./profile.json or ./output.json or ./times.json

Close this bug because the issue is inactivated. Feel free to ask here if you still have question/issue, we will reopen the issue.


fix: not ignore magical creation for nested DTOs;

fixes #701;
I might not see the reasons for it to use the same CreationContext, but it seems to me that there's no one.
There's also some CreationContext next/previous jumping in the Spatie\LaravelData\Resolvers\DataCollectableFromSomethingResolver::itemsToDataClosure but I can't tell if it is connected to the issue.

Came to think about it again, and it breaks the $craetionContext->currentPath consistency.
Can't just yet tell how to fix that.
Side note, possibly a bug:

in the main branch.
if you add here dump($context->currentPath); after the line.
and try that example from #701 but with this data

$someDto = SomeDto::from([
    'name' => 'some',
    'nestedItem' => [
        'name' => 'nestedItem-1',
    ],
    'nestedArrayOfItems' => [
        [
            'name' => 'nestedArrayOfItems-1',
            'nestedItem' => [
                'name' => 'nestedArrayOfItems-1--nestedItem-1',
            ],
        ],
    ],
]);

it outputs

['nestedItem']
['nestedItem', 'nestedArrayOfItems']
['nestedItem', 'nestedArrayOfItems', 0, 'nestedItem']

but should (IMO) output

['nestedItem']
['nestedArrayOfItems']
['nestedArrayOfItems', 0, 'nestedItem']

So it does not go back ($context->previous();) after going into the first nestedItem (nestedItem-1).

As said in the issue, there's a reason why contexts are recycled. We're going to keep that.