create/edit/remove sidecars init container

#975

I should have left a note here or pinged you when I asked for review, that's my bad. The questionable UX of sidecars has come up in meetings a couple times and we decided not to change that for 2.5.8. Since this is the UX that's been in Ember for some time its....'good enough'. Having said that I think there's also some confusion here about bugs vs bad UX

When editing a Deployment with multiple containers only the first can be edited

I think I'm misunderstanding you; I don't see this bug. When I edit a deployment with multiple containers, I get a container-picker view and any container can be edited.

* The container tab also has the pod level properties of label & annotations which i think apply to all containers

Pod labels and annotations only appear there for the main container, but I agree that if it's outside the container scope it should be on a different tab. Related to that, I think having a 'container' tab and then several other tabs that are also within the container spec is a little off so I think names/tab content in general could be improved.

When editing a deployment with multiple sidecars/containers ... the user gets to select a sidecar and then taken to the edit deployment page... however with just edit sidecar tabs

I think this is just a case of confusing UX. All the deployment fields should be present when editing the primary container (if that's not the case then yes, pretty bad bug)

The use of 'container' and 'sidecar' terms leads to a confusing experience (this mostly matches Ember's handling of sidecars)

Agreed, I think we should revisit this along with tab naming/content. Sidecars are just containers.

Cannot set the name of a container, either in create or edit (existing issue in master)

You can't set the name of the "primary" container. You should be able to set the name of additional containers, if not that's a bug.

I don't think there's a way to specifically identify a 'sidecar' container, in some ways it feels we should drop the term sidecar entirely and only use container?

Yeah from what I've read, there's really no formal way of distinguishing them. Sidecars are just one of a few multi-container workload patterns. I think we'll need input from more seasoned kubernetes people than me to decide how we want to present the concept of multi-container workloads, though even we can see pain points with the experience and I think you've got some good ideas going on here. My objection is merely that it's outside the scope of this PR.

Updated to remove primary/sidecar distinction and show deployment-wide config options regardless of which container is being edited. I also added a container select and the ability to add/remove containers to the edit config form:

I've given everything a basic test and think this is almost ready to merge, only two things blocking it

The automated changes to en-us.yaml need reverting and a re-review. This is debatable, however could produce a lot of churn
My changes need a review by Nancy. They look ok and work, though might need

Your changes look good to me, only 2 minor adjustments:

I updated the v-if logic for the remove container button from isEdit to !isView so it can show up when initially creating a container
removed ContainerSelect since it's no longer used

Additionally, I reverted linting on en-us.yaml so changes there should be much easier to review.


Add users connected option

I added the Add users connected number!

Thank you!
If you could I would recommend using git, it is available for windows, mac, and linux. It would make it to where all your changes could be in the same commit (much less messy)


Investigate possibility to support not_in tags

Dump tag name + send information around Dust app.

Closing as marked done


TF 1.0 support and small numpy casting issue

Hi,
Thanks for releasing your code. I just had two quick notes

The function tf.mul is deprecated in favor of tf.multiply. Are you working with the earlier version of TF, by any chance? If so, I will ignore this

I get an error that a float object can't be interpreted as an index. It arises from line 36 in the nvlda.py file, where you initialize with np.ones((1,float)) instead of ((1,int)). I have changed this, and it seems to work after that.

Thanks and regards,
Govind

Thanks Govind, yes I need to update the code for TF 1 (higher) atm it is needs the older version.


0.1.13 regress failure on OpenBSD -snapshots

I get the following FAIL on make regress
test-parm-float-maxvalues... FAIL

Specifically the following when ran independently:
test-parm-float-maxvalues: sqlbox_parm_int convert

Hi James!  What hw architecture are you running?

That's not good at all... I'll spin up a snapshot as well and see what's going on.  FWIW, 7.4 on amd64 works just fine.


Is there a way to use a datalist for auto-complete suggestions?

When I try to use the datalist it is applied to a hidden input field so does not appear for the user.  Am I doing something wrong?  BTW, thank you for the tagfield.  I like it.

No, it's not possible, AFAIK. Only certain types of <input> support this behavior, and not contenteditable elements.


Question: Cross-chain or Multichain

Is assets “native assets” or “cross assets” on Rooch? If it's cross assets, I think we should rather call it cross-chain settlement

@yng17b
Answer： Multi-Chain
It's true that it's as you say from an asset perspective, but we're looking at it from a modular blockchain perspective.
In modular blockchain, we have settlement layer for asserts transfer. And in Rooch, we could support asserts from more than one Layer1, that's why we call it multi-chain settlement.


Rescue ContentItemAppender from Gone responses

The endpoint /api/content/ now responds with a 410 response.
The ContentItemAppender should just swallow this error like it already
does with 404.

Closing this, as we shouldn't need it. 410 errors were caused by an unrelated API failure on GOV.UK.

There is still a 410 that comes back when trying to access the homepage from the prototype, so we do need this after all.


Consider removing support for float128 (long double)

This library supports float128 (long double) fields in messages [1], presumably because the OMG IDL spec mentions them (see section <IP_ADDRESS>.4.2.2).
However, the OMG specification leaves the exact definition of a long double ambiguous: "The long double data type
represents an IEEE double-extended floating-point number, which has an exponent of at least 15 bits in
length and a signed fraction of at least 64 bit" (emphasis mine). It is important to note that this ambiguity means that the binary representation of a long double is not generally safe to transmit across applications since the applications may be generated by different compilers or against different platforms which may have incompatible binary representations of a long double, leading to invalid data if they interpret the format wrongly.
The IEEE extended floating point formats were conceived for performing internal computations at higher precision to minimize round-off errors, which is why their specification is ambiguous: They were meant to be invisible to programmers, not serialized and transmitted, so it was not considered important to be firm about their definition.
Presumably OMG IDL includes long double for the sake of completeness, in case some user has some reason for serializing and moving intermediary calculation cache data around within their application, but this seems like an extremely caveat emptor situation.
Since a key goal of ROS is to be accessible to users who are not experts in computing or binary representations, free of the landmines and gotchyas that come with ambiguous specifications, I think it would be reasonable to argue that we should not consider the movement of intermediary extended floating point calculations within a single application to be a valid use case for ROS. The only way that transporting a long double can be safe is if we also encode and enforce the binary representation, and we do not currently have a reasonable way to do that.
In terms of support across different middlewares:

CycloneDDS explicitly does not support long double
FastDDS does support long double, but it does so by reinterpreting the binary data as a const char* and copying the raw value into the serialized data, which means it will only be interpreted correctly if the producer and consumer of the message were compiled for architectures that use matching formats.
Similarly ConnextDDS leaves it to the user to ensure the long double is interpreted correctly across different applications: "If a distributed system uses different long double representations, the applications are responsible for manually interpreting the individual bytes (provided as Int0 to Int3)."

While the ROS IDL design docs mention support for long double, it has never made it into the builtin types list for ROS IDL, so there is currently no way for ROS users to transmit long doubles anyway outside of this dynamic typesupport library.
I think long double is a massive footgun for ROS users that adds no tangible value, so for the sake of safety and soundness I propose that we eliminate its presence from this dynamic type support library, and also remove it from the "Supported subset of IDL" list in the ROS IDL design doc.

Thanks for laying out the issue so well.  I also took a look around the ROS ecosystem (at least, all of the packages released into Rolling), and as far as I can tell nothing expects to be able to transmit float128 on the wire currently.
I'm going to bring this up at the next ROS PMC meeting to see if anyone has objections or additional thoughts about removing this support.

@clalancette I will not be able to attend the PMC meeting, but I have no objections about removing support for float128.


module circular reference GetExportedNames/ResolveExport bugs

GetExportedNames(): module namespace binds all names from
GetExportedNames(nullptr). However we incorrectly cached result from any
GetExportedNames(exportStarSet) call. This causes module namespace
having incomplete names, because a previous intermediate call with non-null
exportStarSet did not include names from that set. This fails 3250-ext-a.
Found this problem while investigating #3250. Fixed by only cache/reuse the
result if exportStarSet is nullptr (root call).
ResolveExport(): parameter exportStarSet were used to prevent infinite
loop when looking up name under module circular references. However it
broke the case that we lookup this module record recursively for a
different name (indirect). This causes #3250 to throw SyntaxError for
failing to resolve a binding (resolving f_indirectUninit for dep2, reenter
to resolve c_localUninit1 but rejected by exportStarSet). Fixed by
removing it -- another parameter 'resolveSet' already does the job well. It
prevents recursion for the same {moduleRecord, name}, but allows looking up
a different name.
Finally, moved a fragment into try/catch and added an ENTER_SCRIPT_IF. The
given call may throw JavaScriptException which requires in script.

Thanks @suwc !


Include GitHub link from Styleguide site

From what I've found one needs to visit the releases tab to see changes. To more easily access that and this repo I'd suggest we add a classic GitHub icon to the site.
:octocat:

Go ahead and make a pull request 👍


Validators as functions

Augments register_validator to accept functions (as well as Validator classes).

I've added the changes we've discussed. In BaseModel guards, validators must now be specified either as a validator class instance, or as a (validator, on_fail) tuple, where validator can be either a registered class/function validator or a validator name.
I've noticed that we do actually use pydantic validators in the validation process. Specifically, they're treated as reask validators by default. This is now made explicit in 9e7bf1a. Did I miss a way to customize what a pydantic validator's on_fail attribute is? If not, we should consider how to set that, or consider excluding them from the validation process.


AD5263 support possible?

Hi Rob,
Would it be possible to include support for the AD5263?
I am specifically looking for an Arduino library which supports a 4 channel, 256 step digital potentiometer, with I2C interface.... (It needs to be compatible with an RP2040 microcontroller, but I do not see any issue with the libraries of you I have been using so far, so I expect that will be no problem)
If needed, I am willing to sponsor the development of a library. :-)  (In that case please contact me at my username AT gmail)
Thanks!
Paul

Thanks for the issue.
Such a library should be possible, need to the datasheet (download), a way to test (you?) and some time.
Not seen the datasheet, I assume it is a straightforward device so it should take 4-8 hrs to set up the things incl build infra and initial documentation.
Will download datasheet later today to see if there are surprises.
Do you need it fast?

downloaded datasheet
created a placeholder => https://github.com/RobTillaart/AD5263

I move this issue to that repository.


Test-DbaConnection accepts multiple instances and return one object

Type of Change

[x] Bug fix (non-breaking change, fixes #2146)
[ ] New feature (non-breaking change, adds functionality)
[ ] Breaking change (effects multiple commands or functionality)
[ ] Ran manual Pester test and has passed (`.\tests\manual.pester.ps1)
[ ] Pester test is included

Purpose

Conform the command to our standards ensuring:

one complete object is returned.
accepts multiple instances.
general format

Approach

Allows us to now test multiple instances in one command
Commands to test

Test-DbaConnection sql2016a,sql2016b,sql2016c

Test-DbaConnection sql2016b | select *

Screenshots

very prettty <3


requestOptions removes functions options

Hello,
I need to define a jsonReplacer to request, but unfortunately it's a function option which is removed by traverson/lib/merge_recursive.js merge function.
Any reason to specifically removing functions properties in the merge function ?

This definitely sounds like a bug. I'll look into it. Thing is, I'm on vacation right now, it might be a while until I can do so.

Hello,
Thanks for taking a look so quickly on this (while on vacation!)
It fixes the requestOption.jsonReplacer to be taken into account ...
But I had to open #68 for being applied :smiley:

fix has landed in release 3.2.0


685 fixed blank error message showing

Description
Fixed the instances of blank error messages by making sure the CHAT_MESSAGE_TYPE enum was synced on the frontend and backend.
Notes

The blank error message was the result of the frontend trying to display the system role as a message.

Checklist
Have you done the following?

[x] Linked the relevant Issue
[x] Added tests
[x] Ensured the workflow steps are passing

Whoops, I'd taken these out because I couldn't find anywhere that they were used. was I mistaken?

mind adding a comment to make it clear that these two are needed for syncing so another developer like me doesn't remove them with good intentions

Yep can do, I've kept it general in case more values are added on the backend which aren't used on the frontend.


Supabase support

Hi , wondering if you will support supabse in near future

can you help me with minimu abstract emthods that are required for this , i can do PR

A good starting point for creating a new document store from scratch is using this repo as a blueprint: https://github.com/deepset-ai/document-store
Also looking at existing document stores in this repo, like https://github.com/deepset-ai/haystack-core-integrations/tree/main/integrations/chroma might help getting started.

Hi @mayankodin,
When you said "supabase support" , do you mean supabase ai and vectors ?

We decided not to add a Supabase Core integration for now, contributors can still create an integration they own and maintain.


Possible error on Content-Type Header detection

I'm trying to send DTMF in SIP INFO request and I always got a missing content-type error  :

SipDialogController::doSendRequestInsideDialog - Error: missing content-type

In my Nodejs code I put a content-type header but it's not seen in sever part.

app.request({
method: 'INFO',
stackDialogId: dialog,
headers: {
'User-Agent': 'dracht.io',
'Content-Type': ' application/dtmf-relay'
},
body: messageBody
}, function(err, req){}

Looking at  SipDialogController::doSendRequestInsideDialog line 177 I found  that !searchForHeader( tags, siptag_content_type, contentType )  is using siptag_content_type and not siptag_content_type_str.
It may be the reason of issue in content-type header detection.

Hi there!  Thanks for point this out.  It looks like you are testing with the master branch -- it's my fault but that branch is way behind.  Can you switch to the develop branch, where I believe I fixed this issue?  Let me know if it is still an issue there. (separately, I'll work on merging develop into master, but please just use the develop branch going forward)

Ok thanks Dave.
I switch to develop branch and it works. I can send my DTMF with SIP INFO request to my Asterisk PABX from my WebRTC gateway.


401 response should contain CORS and "WWW-Authenticate" headers

StatusUnauthorized 401 error response should always have a specific "WWW-Authenticate" header https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/WWW-Authenticate
Also should reply with CORS headers.
This allow the frontend running in different origin (port 3003) to get the status error code and not a generic error like Failed to fetch. See: https://github.com/axios/axios/issues/960
Please review @tiero @altafan

@Janaka-Steph please, add this line to Encrypt/Decrypt functions.
Also, it would be enough to check that the hash of the given password matches the vault's one instead of actually decrypting the encrypted mnemonic.


Unclear abbreviation GC extension

I am reading the manual for the first time and could not understand what GC stands for:
https://github.com/riscv/riscv-isa-manual/blob/10eea63205f371ed649355f4cf7a80716335958f/src/intro.tex#L352-L352
C extension makes sense, but G extension does not exist. Is this a bug or feature?

GC means "General with Compressed", I think. The RISCVxG extension contains the I, A, M, F, and D instruction sets. The C part of that acronym means that the C instruction set extension is added for compressed instructions.

Makes sense, thanks!
If you are right, then G should be defined in the intro to avoid confusion. What do the authors think?

Agreed, the forward reference to G probably resulted from years of editing.  Fixed.


When generating random strings, make sure they do not contain dots.

Useful to save these strings as keys in MongoDB documents.

This is on my todo list to sort out. There are a couple of problems with our current approach:

the presence of the '.' causes headaches for some down-steam systems
the code is repeated in too many places
the id's can be variable length (ok, not a real problem, but it hurts my OCD when the ID's don't line up).

So whilst your approach of a simple replace() addresses the '.' issue, if we're going to change it, I'd like to take the time to address the other issues.

Do you have any suggestion for where to put a global randomId() function?

This is probably overkill, but have you seen how Firebase generates pushID's? They have a lot of very attractive properties in terms of a GUID...
https://gist.github.com/mikelehen/3596a30bd69384624c11
https://www.firebase.com/blog/2015-02-11-firebase-unique-identifiers.html

We updated how NR generates node ids - they no longer contain .


add docs for how to create draft plugins

@bacongobbler just added support for running powershell scripts on plugin hooks. We should write some docs up explaining how to create a draft plugin from scratch and with the additional info on windows support.

just kidding found the dep for it:

Should we keep this issue or #540? 😄

We should keep this one open since it has more background context. I just closed #540. Thanks for pointing that out!


Bundle some basic markdown manipulation tools with mystmd (for both Python and JavaScript)

As people use MySTMD more heavily, they may run into cases where they want to build custom plugins or do scripting with MyST documents. A nice example of this is Rowan's auto-generated MEP table.
In these cases, it's common to do some manual parsing of MyST files in order to grab metadata, read page content, etc. This usually involves some clunky workflows where you try to remember how to parse a markdown file, parse the YAML header, and turn it into a dictionary.
Proposal
It would be helpful if MyST provided some basic "MyST Manipulation" tools as helper functions to encourage more standardized development and lower the energy barrier there. For example (and with arbitrary names):

myst.read_metadata("myfile.md/ipynb") would read the YAML metadata of a MyST markdown or ipynb file, and give it to you as a dictionary.
myst.read_contents("myfile.md/ipynb") would do the same but with some kind of AST-like representation of the content.

Don't have strong opinions on the specifics, I just wanted to give the above two functions as examples!

Yes! That would be very nice. Here is are some use cases for education:

Parse all myst files in my course, and extract all definitions (e.g. marked up as admonitions with 'Définition' in the title) to generate flashcards
Parse all myst files in my course, and extract annotations (as a step toward adaptative learning with Jupyter, I am experimenting with adding annotations about the various learning objects in the course).
3.Parse all myst files in my  course, and split in chunks to feed to a RAG.
Parse all myst files in my course, and extract a short review document with all definitions, theorems, and other important things to remember.

It would be very convenient to be able to:

implement 1,2,3 above by providing some custom roles and directives and letting myst parse the ast and run the roles and directives to harvest the information.
implement 4 above by providing some custom roles and directives and letting myst parse the ast, run the roles and directives, and reexport a myst document.

All in all, this is of the same flavor as xslt which was about making it easy to harvest and transform xml files without having to rewrite the parsing logic.


Add support for use_squash_pr_title_as_default

Github added some months ago this nice option --> https://github.blog/changelog/2022-05-11-default-to-pr-titles-for-squash-merge-commit-messages/
And, as far as I understand, the terraform provider for github already has it. https://github.com/integrations/terraform-provider-github/pull/1263
I don't think I have seen this option in the variables, nor any related issue.
Am I missing something? And, if not, is this something expected to be added?

Hi @soerenmartius !
Thanks a lot for the super quick reply.
I think from version 4.31 onwards the change is there https://github.com/integrations/terraform-provider-github/releases/tag/v4.31.0
I forked this repo, updated version.tf and added the new variables, and it does seem to work, but documentation on these two fields seems a bit lacking to me. After a couple of tries I got it working perfectly, but I'm not 100% sure about retro compatibility - adding these two fields, even with null value, throws this:
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.testrep.github_repository.repository will be updated in-place
  ~ resource "github_repository" "repository" {
        id                          = "testrep"
        name                        = "testrep"
      ~ squash_merge_commit_message = "COMMIT_MESSAGES" -> "false"
      ~ squash_merge_commit_title   = "COMMIT_OR_PR_TITLE" -> "false"
        # (31 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

So for people specifically wanting to have this feature (in my case, default the squased title to the PR title) works great, otherwise might cause some headaches.
Additionally, if you add some value to squash_merge_commit_title but not to squash_merge_commit_message you might receive some nasty, totally undescriptive errors, like in this situation:
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.testrep.github_repository.repository will be updated in-place
  ~ resource "github_repository" "repository" {
        id                          = "testrep"
        name                        = "testrep"
      ~ squash_merge_commit_message = "COMMIT_MESSAGES" -> "false"
      ~ squash_merge_commit_title   = "COMMIT_OR_PR_TITLE" -> "PR_TITLE"
        # (31 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

module.testrep.github_repository.repository: Modifying... [id=testrep]
╷
│ Error: PATCH https://api.github.com/repos/ultimateai/testrep: 500  []
│
│   with module.testrep.github_repository.repository,
│   on .terraform/modules/testrep/main.tf line 94, in resource "github_repository" "repository":
│   94: resource "github_repository" "repository" {

It doesn't make that much sense that it fails, but I get it. However, I would have explained it a little bit better in the docs.
Hope any of this information is useful to you, and thanks a lot for this module. Is really useful!

Hi @robgutsopedra, thanks for the heads-up! I've implemented the feature in https://github.com/mineiros-io/terraform-github-repository/pull/137 and will get back to you once someone of our team reviewed the PR and when we issued a new release.
Regarding the described issue, unfortunately the GitHub provider is broken in many circumstances :(

Hey @soerenmartius !
I'd love to have this feature, it would help me quite a lot with some automation I'm working on <3
I see the PR https://github.com/mineiros-io/terraform-github-repository/pull/137 has been stalled for some weeks now, could I lend a hand with something?


Can not find it in either Mobile or Desktop Plugin ‘store’

Describe the bug
Title says it all!

Ah! BRAT…great!. Hope you know someone in the app development team that will approve it when you’re ready….😉

Would you be willing to send me the URL for BRAT?Thanks.Dave BOn Apr 20, 2023, at 10:12 AM, Stephan Ango @.***> wrote:
It hasn't been submitted yet.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

It's the same as the URL of the repo
https://github.com/kepano/obsidian-serenity

Successfully installed and working like a charm. Thanks for the opportunity to get in on the ground floor.

Great.


Make is really obvious that the "dev" docs are for unrelease/development versions

It's not uncommon for users and search engines to find the dev docs and read them as "latest", the only real way to tell is the URL:
http://numba.pydata.org/numba-doc/dev/index.html
vs
http://numba.pydata.org/numba-doc/latest/index.html
i.e. dev vs. latest or that the release number is different, i.e. it's 0.49 vs 0.48 at present, however, unless you keep track of Numba development closely, that 0.49 isn't released yet is unlikely obvious.
Suggested fix: Make it really obvious that the "dev" version is for an unreleased version of Numba, perhaps add a header/banner to all pages expressing this and where to get dev builds and where the latest released version docs are?

👍


[Roadmap] Real-time dashboard

Provide a real-time dashboard:

Polling for data
Show visitors as they come in
Show active urls being visited
Show real-time country highlights

This is awesome, looking forward to it! :)

Sneak peek of WIP

@mikecao Looks great! When do you think this will be in a new docker image? No rush eh :D


Add type casts for functions used as values

A bit of a shortcoming of TS type checking is that here:
function apply<T, U>(f: (a: T) => U, x: T): U {
  return f(x);
}

function id<T>(x: T): T { return x }

let a = 3
let b = apply(id, a)
let c = apply(x => id(x), a)

only c has type number, b is resolved to type {} which is something on which nothing is allowed.
Without re-introducing the lambda, a solution is to have functions used as values annotated with the resolved type at that point:
let d = apply(<(x:number) => number>id, a)

Just to note: this would fix collection proxies that do stuff like List.map List.ofArray ..., such as List.chunkBySize, List.splitInto, List.windowed.


[SPARK-31804][WEBUI] Add real headless browser support for HistoryServer tests

What changes were proposed in this pull request?

This PR adds two things.
Real headless browser support for HistoryServer tests.
A test suite using headless Chrome as one instance of those browsers.
Why are the changes needed?

The motivation is same as #28578 .
In the current master, there is a testcase for HistoryServer which uses Ajax so we need the support for HistoryServer tests.
Also this change is necessary to upgrade HtmlUnit (See #28585)
Does this PR introduce any user-facing change?

No.
How was this patch tested?

I tested with following patterns. Both Chrome and Chrome driver should be installed to test.

sbt / with chromedriver / include tag (expect to succeed)
build/sbt -Dspark.test.webdriver.chrome.driver=/path/to/chromedriver "testOnly org.apache.spark.deploy.history.ChromeUIHistoryServerSuite"

sbt / with chromedriver / exclude tag (expect to be ignored)
build/sbt -Dtest.exclude.tags="org.apache.spark.tags.ChromeUITest" -Dspark.test.webdriver.chrome.driver=/path/to/chromedriver "testOnly org.apache.spark.deploy.history.ChromeUIHistoryServerSuite"

sbt / without chromedriver / include tag (expect to be failed)
build/sbt "testOnly org.apache.spark.deploy.history.ChromeUIHistoryServerSuite"

sbt / without chromedriver / exclude tag (expect to be skipped)
build/sbt -Dtest.exclude.tags="org.apache.spark.tags.ChromeUITest" "testOnly org.apache.spark.deploy.history.ChromeUIHistoryServerSuite"

Maven / wth chromedriver / include tag (expect to succeed)
build/mvn -Dspark.test.webdriver.chrome.driver=/path/to/chromedriver -Dtest=none -DwildcardSuites=org.apache.spark.deploy.history.ChromeUIHistoryServerSuite test

Maven / with chromedriver / exclude tag (expect to be skipped)
build/mvn -Dtest.exclude.tags=org.apache.spark.tags.ChromeUITest -Dspark.test.webdriver.chrome.driver=/path/to/chromedriver -Dtest=none -DwildcardSuites=org.apache.spark.deploy.history.ChromeUIHistoryServerSuite test

Maven / without chromedriver / include tag (expect to be failed)
build/mvn -DwildcardSuites=org.apache.spark.deploy.history.ChromeUIHistoryServerSuite test

Maven / without chromedriver / exclude tag (expect to be skipped)
build/mvn -Dtest.exclude.tags=org.apache.spark.tags.ChromeUITest -Dtest=none -DwildcardSuites=org.apache.spark.deploy.history.ChromeUIHistoryServerSuite test

Test build #123033 has started for PR 28622 at commit e5ee94e.

Merged build finished. Test PASSed.

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

Test build #123034 has started for PR 28622 at commit 4db2833.

Merged build finished. Test PASSed.

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

Test build #123033 has finished for PR 28622 at commit e5ee94e.

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

Merged build finished. Test PASSed.

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

Test build #123034 has finished for PR 28622 at commit 4db2833.

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

Merged build finished. Test PASSed.

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

Existing tests in HistoryServerSuite should still run on the CI environment except one test which I moved to ChromeUIHistoryServerSuite.
If we can, it's better to enable such tests to run on Jenkins.

Please hold on this because the original PR breaks master branch. This can propagate the failures into new suites. Please see https://github.com/apache/spark/pull/28578#issuecomment-633153398 .

retest this please

Merged build finished. Test PASSed.

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

Test build #123047 has started for PR 28622 at commit 4db2833.

@HyukjinKwon Thanks for taking a look at this. Tests in this PR will fail until #28627 is merged because this PR doesn't contain the way to skip suites with ChromeUITest.

Test build #123047 has finished for PR 28622 at commit 4db2833.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Oh, I see. Thanks :D.

Test build #123307 has started for PR 28622 at commit a852a5d.

Merged build finished. Test PASSed.

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

ChromeUITest is introduced by #28627 so now this change should be available.
I've updated the test patterns in the description.

Test build #123307 has finished for PR 28622 at commit a852a5d.

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

Merged build finished. Test PASSed.

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

@sarutak to be clear we can merge this, or does another need to come first?

Now we can merge this and the next is #28585.

Merged to master


[SPARK-50517][PYTHON][TESTS] Group arrow function related tests

What changes were proposed in this pull request?
Group arrow function related tests
Why are the changes needed?
test clean up
Does this PR introduce any user-facing change?
no, test only
How was this patch tested?
ci
Was this patch authored or co-authored using generative AI tooling?
no

Ur, @zhengruifeng and @HyukjinKwon .
According to the content, this is more arrow-related tests instead of pandas related tests. Did I understand correctly?
I'm curious about the relation between this and the previous pandas PR (the following).

[SPARK-50507][PYTHON][TESTS] Group pandas function related tests #49074

Thanks for the reminder, you are right they are for arrow


Async validation in ng-accept

Hey,
I'm using using ng-accept for checking size of selected files and their type.
I've wanted implement mechanism to checking dimensions of selected image file but in that specific case getting image size is asynchronous thus I couldn't return boolean in validate function passed to ng-accept.
It could be great if function passed to ng-accept could return plain boolean (sync way) or a promise (async way).
Below is link to jsfiddle which shows the problem.
http://jsfiddle.net/29a7a0vt/4/

Could you submit a PR?

I'll try at the weekend use some code that I wrote for my own directive (just wrapper for ng-file-upload) and if everything will go smoothly I will add PR :racehorse:

ngfValidateAsync is added to the latest versions.


imported staff apps that have no location assigned need way to set locaiton

if the staff app is in the list for location 0 then there is a way to set what location it is for.

now working


Perf_tool_backend doesn't recognize "tr strt tr end"

This shows up for me in our Go demo. E.g. we fail to parse this perf line:
"2118573/2118573<PHONE_NUMBER>07116:   tr strt tr end                      0 [unknown] =>           4591e1 [unknown]"
I included a commented-out test for this in my recent pull request to the line-parsing code, for convenience of whoever fixes this.

Both Tudor and I think it should probably be interpreted as a Jump. But it's hard to verify that with the Go example because it's broken for unrelated reasons, too.


Change UnexpectedEnd to include the expected size

Right now the enum variant of ErrorKind UnexpectedEnd is void. I suggest changing it to UnexpectedEnd(usize) so the caller will be able to know how much data it is missing for success.
This will allow development of stream protocols to be more efficient by reserving buffers & calling the decode only when data is complete.
More specifically, I'm now developing a actix-codec Encoder/Decoder and I'd wish to reserve the additional missing data before returning.
Thoughts?

#[derive(Decode)]
struct Foo {
    a: u64,
    b: u64
}

Because bincode does not have a look ahead system, if you feed this struct only 1 byte, it would report a UnexpectedEnd(7) as u64 needs 8 bytes. Not the 15 bytes it actually needs. Would this be good enough for your case?


Rbac init error

When doing "yii rbac/init" an error appears: PHP Compile Error 'yii\base\ErrorException' with message 'Declaration of common\rbac\rules\AuthorRule::execute() must be compatible with yii\rbac\Rule::execute($item, $params)'
Had to edit _protected\vendor\yiisoft\yii2\rbac\Rule.php. I've changed this "abstract public function execute($item, $params);" to this "abstract public function execute($user, $item, $params);"

There was some silly mistake in my migration, I've fixed it in 2.2.1. But other than that rbac/init should work without hacking framework. Have you installed rbac tables by running migration ./yii migrate ? You have done all the steps of the installation process described in the guide ?

Sorry, my bad. I missed one important step. I've done a fresh installation of composer before and I've missed to do this: < composer global require "fxp/composer-asset-plugin:~1.0.0" >
Now I've done it all from the beginning (after installing composer asset plugin) and everything works great. Thank you!

No problem


Pin Pillow to 10.1.0 to make Snyk happy

Snyk reports a vulnerability in Pillow versions < 10.0.0. We don't pin Pillow, which means that Wagtail in practice pulls in the most recent version, which is greater than 10.0.0, BUT for some reason this doesn't satisfy Snyk.
Snyk keeps reporting this vulnerability on all of our cf.gov PRs. In order to make Snyk happy, let's pin Pillow to the currently installed version, which is 10.1.0.
Screenshots
Here's what Snyk reports:

Even though in practice we are already getting Snyk 10.1.0:
$ /srv/cfgov/current/venv/bin/pip freeze | grep illow
Pillow @ file:///srv/cfgov/versions/20231129110504/wheels/Pillow-10.1.0-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl#sha256=fa1d323703cfdac2036af05191b969b910d8f115cf53093125e4058f62012c9a

Checklist

[x] PR has an informative and human-readable title
[x] Changes are limited to a single goal (no scope creep)
[x] Code follows the standards laid out in the CFPB development guidelines

Snyk is still reporting this issue:

Note they claim to have tested commit e4af3426 which is this commit, which pins Pillow. @lfatty any idea why Snyk is still failing?

@willbarton I agree it's not optimal. My goal is to make Snyk happy so our PRs don't keep failing this check. It's just unclear to me how Snyk is actually checking this - for example the current failure shows the vulnerability coming from<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>but:

<EMAIL_ADDRESS>doesn't actually specify<EMAIL_ADDRESS>it specifies wagtail>=2.15
<EMAIL_ADDRESS>doesn't actually specify<EMAIL_ADDRESS>it specifies Pillow>=9.1.0,<11.0.0

My best guess is that maybe at some point Snyk scanned<EMAIL_ADDRESS>and at that time the latest version of Wagtail was 5.0.5, and at that time the latest version of Pillow was 9.5.0? I can't find any way to get Snyk to do a total re-assessment of all of its dependencies.

it's pinned upstream from us

From Snyk's POV it doesn't actually see that upstream pin because it checks libraries.txt separately from wagtail.txt, so it doesn't see our Wagtail pin.
Would you be alright with trying this PR to see if it satisfies Snyk? If not, we might need to remove Snyk or find a way to permanently ignore this error.

We can try I guess?
That kind of ambiguity though is exactly what the pip-compile workflow I tried to introduce should avoid though because it means Snyk would be scanning the full set of dependencies as pinned and hashed the last time we compiled them.

Thanks @willbarton. Let me try this and if Snyk doesn't recognize it, I'll revert. Agree we should revisit #7874.

Frustratingly, this didn't work - Snyk still reports the same vulnerability.
But I figured out why it is doing that! It turns out, buried in the documentation, that when Snyk scans using requirements files, you can only choose Python versions 2.7.16 or 3.7.4. In our case, because we've chosen Python 3, we're testing with 3.7.4 (not 3.8 which we actually use in production).
The latest Pillow version supported for Python 3.7 is... the vulnerable 9.5.0! Support for 3.7 was removed in Pillow 10.0.0 although unfortunately this isn't mentioned in the release notes. So this is where the Pillow vulnerability is coming from.
Snyk does support more recent versions of Python if you use Pipenv, see docs here. Alternatively if you use Poetry they scan the exact dependency tree you provide.
Given that @willbarton, any thoughts on how to proceed? It seems like I could remove this pin and permanently ignore Pillow in Snyk (sorry @lfatty):

Then we'd no longer have the red X on all of our PRs, but Snyk would essentially be testing versions we're not even using. Snyk doesn't seem particularly useful for Python testing if it's not even testing using our version of Python..

I don't love ignoring Pillow, because that's where a lot of our regular vulnerabilities on the Python side come from.
I also... the Python version thing boggles my mind. We could use Poetry, I guess, instead of pip-compile, but that'd be a vastly larger disruption to our workflow, without much benefit (IMHO) aside from making Snyk happy?
My preferred approach would be for Snyk to support vanilla Python > 3.7!! That's bonkers. Aside from that, the alternatives seem entirely to make Snyk happy at the cost of extra complexity for us. So... I really don't know.

Snyk doesn't seem particularly useful for Python testing if it's not even testing using our version of Python..

:100:


AccordionItem ChevronUp and ChevronDown not showing

Describe the bug
All accordion examples icons disappears when you toggle.
When you refresh the page, they appear again.
Reproduction
n/a
Flowbite version and System Info
n/a

Same in the Sidebar component.

It is because of Chevron component problem. Since these are in the library components, I will replace them with SVGs.


Knowledge Panels: Implement the first version of the draft UI

Description
Implement the first version of a rendering UI for generic KPs.
Demo
[On a local environment]
Search for a product
Click on the result to open the product page
Click on the eco-score
See the knowledge panel.

Fixed. Thanks @jasmeet0817 👍
Closing this bug.


ModuleNotFoundError: No module named 'llama_recipes'

🚀 The feature, motivation and pitch
when i cd llama-recipe and do torchrun xxx，error：ModuleNotFoundError: No module named 'llama_recipes'
how to solve？
Alternatives
No response
Additional context
No response

Have you tried install with pip?

Try this in the llama-recipe folder.
pip install -e .

I have already solved this problem. In the current main branch, the directory location is incorrect, and it is necessary to replace src/llama_ Place the recipes in the previous directory, and then place the finetuning. py in the previous directory

@qing-yuan233 yes, we changes the directory structure for the packaging process. Easiest is to run installation from source as pointed out above. Closing this as you're solved your problem.


Actions are failing

The actions to build and publish new images are currently failing, see for example: https://github.com/hdl/containers/actions/runs/8289693629
Possibly related to credential at docker.com?

will somebody fix this?

It was related to credentials at gcr.io (see https://hdl.github.io/containers/dev/Tasks.html). Fixed/updated now.


[Statie] Take care of elements in anchor linker

New code strips all tags from id attribute and does not generate  element when title contains some (in any part of the title).
Let's have a look on two possible cases:
1. heading contains some html element
Consider heading on input

Hi Tom

Before:

  Hi Tom

After:

  Hi Tom

2. heading contains  element
Consider heading on input

  Impactful Storytelling for Innovators and Disruptors

Before:

  Impactful Storytelling for Innovators and Disruptors

After:

  Impactful Storytelling for Innovators and Disruptors

I'll also update https://www.statie.org/docs/headline-anchors/ to cover new logic and add some code on how to display anchor on hover in both cases.

Hi @crazko,
thanks for the tests and fix at once!
Is this ready to merge now?

Yep, it is.
On Sun, 17 Mar 2019, 21:19 Tomáš Votruba<EMAIL_ADDRESS>wrote:

Hi @crazko https://github.com/crazko,
thanks for the tests and fix at once!
Is this ready to merge now?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Symplify/Symplify/pull/1500#issuecomment-473710740,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABMqNVepcSxr5_eY4e-bOr7NlHfgzKt5ks5vXqNggaJpZM4b33rY
.

Thank you


Optimizations on Core

During review check optimizations in regard to work duplication (e.g. beta reduction)

See #267


Blank Dashboard and Discover Screen

@emertoglu commented on https://github.com/opensearch-project/OpenSearch/issues/5842
My scenario is as follows.
I created 2 roles[role1, role2] , 2 users[user1, user2] and 2 tenants[tenant1, tenant2] and I mapped roles to users.
I loaded the data with two different index names[index_u1-, index_u2-]
user1 index_u1-* and user2 index_u2-* have read , write manage index permissions
when i sign in with a user name and password, i see a blank screen. The Dashboard and Discover screens are blank and I can't create anything.
if I map the role of kibana_user to users, users can create dashboards, but this time they can see someone else's dashboards (they can't see the data because the indexes are different)
if I map all_access role to users, users can create dashboards, but this time they can see someone else's dashboards and data (although the indexes are different)
how can i fix the problem?
This issue was related with setup and usage by using security feature, transfer this issue from anywhere repo to security repo manually for now which required two repo permission
CC: @minalsha @seraphjiang @peternied

[Triage] Hi @Flyingliuhub, thank you for reaching out to the OpenSearch team. I wanted to take a moment to direct you to the forum where your issue may be better addressed.


psh: modularization of psh applets

each applet separated into its own directory
each applet registers its command(s) in list using constructors
interactive psh separated as applet "pshapp"
login separated as applet "login"
remodelled "help" to work with modularized applets

Applets modularization into directories does not support subtrees in those directories.
Each applet must register itself using staticly defined list element passed to list in psh.
Each applet can register more than one command in psh but no ordering is done during registering.
A command may be hidden from "help" by not specifying info function (passing NULL in constructor).
Above changes achieve good psh modularization and simplifies process of new applet creation.
JIRA: PD-74

i would not say that each command has its own directory. You are mostly right, as currently majority of applets are dir = one command but the point is each applet has its own directory and each applet can register multiple commands if needed. Future refactoring can, for example, join mount and bind under one applet (directory) (as these commands do somewhat similar thing and can share some of code). However bigger advantage is that bigger applets can be split into multiple files for better readability. Candidates for that are: pshapp and ls but future applets may appear.
no, your Makefile seems to work just right :)

history not initialized is my valid error during pshapp applet modularization. I will correct it.
login --help or login -h has to be added as it must be clarified what does this command do: sole login applet just authenticates user. Other applets may use it to authenticate the operation (just a little step to permissions in Phoenix) and it is currently used like that by pshapp when called as pshlogin. Sole login applet is exitable by ctrl+d. So calling it by user just authenticates you to nothing - not harmful but not useful (note that it is not listed in help as it is not very helpful on its own)
I am going to check each applet for -h option
maybe help -a option to list even hidden commands should be implemented

about not firing up psh, or rather pshapp when typing psh:

my intention was that there can be only one interactive shell for one psh process
so that if you want new shell you need another psh process using / (well, basically a new shell :) )
also a reason was that you cannot exit pshlogin shell completely so there would be no way back from multiple pshlogin commands
command psh not listed in help so its a hint that this command, although enter-able, is not useful
we can still work around it if we want it to spawn a new process if needed

@nalajcie multiple comments:

i would not say that each command has its own directory. You are mostly right, as currently majority of applets are dir = one command but the point is each applet has its own directory and each applet can register multiple commands if needed. Future refactoring can, for example, join mount and bind under one applet (directory) (as these commands do somewhat similar thing and can share some of code). However bigger advantage is that bigger applets can be split into multiple files for better readability. Candidates for that are: pshapp and ls but future applets may appear.

no, your Makefile seems to work just right :)

history not initialized is my valid error during pshapp applet modularization. I will correct it.
login --help or login -h has to be added as it must be clarified what does this command do: sole login applet just authenticates user. Other applets may use it to authenticate the operation (just a little step to permissions in Phoenix) and it is currently used like that by pshapp when called as pshlogin. Sole login applet is exitable by ctrl+d. So calling it by user just authenticates you to nothing - not harmful but not useful (note that it is not listed in help as it is not very helpful on its own)

I wanted to check if login works, my main objection is that I don't know if it succeeded or not - so I don't really know how to test it. If there would be an automatic test for that, I wouldn't need to check it manually :P.
Side note: AFAIK the original login tries to ask for password 3 times and then exits. Because of that it's easy to see that I failed the pass (aside from "Login failed" ;)).

I am going to check each applet for -h option

maybe help -a option to list even hidden commands should be implemented

about not firing up psh, or rather pshapp when typing psh:

my intention was that there can be only one interactive shell for one psh process
so that if you want new shell you need another psh process using / (well, basically a new shell :) )
also a reason was that you cannot exit pshlogin shell completely so there would be no way back from multiple pshlogin commands
command psh not listed in help so its a hint that this command, although enter-able, is not useful
we can still work around it if we want it to spawn a new process if needed

If psh does nothing, it should not be available as an applet. Btw, I think this a change in how psh works, so it should not be hidden within refactoring PR - and the change in behavior should be clearly stated. Not sure what will happen if I would try to execute script using psh shell inside interactive shell...
Not directly related to this PR, but worth noting for the future - on targets with signals implemented not spawning a subprocess  for (at least) some of the applets will break the expected POSIX compliance (but maybe we don't care about that as we don't want to be a POSIX sh). For more info - read about NOFORK configuration option in busybox and why sleep needs to be forked :).

Sorry for long login response, I misunderstood your comment as somehow related to not spawning new shell :)
As for process spawning: it only applies for interactive shell - the check for pshapp_common.isrunpsh is only done when starting interactive shell routine, so scripts can run normally.
To clarify - the pshapp_common.isrunpsh does not permit the sturtup of pshapp but rather it controls that applet run. It can permit only the startup of interactive shell but already inside the pshapp.


support sending an existing schema to deduce_schema

support sending an existing schema to deduce schema so we can merge an existing BigQuery schema with new rows in file.
Something like:
def deduce_schema(self, file, schema_map =None):
if schema_map is None:
schema_map = OrderedDict()

Hi, Can you provide more details about where and how you would use this feature? It sounds like you want to incrementally build the bigquery schema, based on new rows. But it's not clear to me how this would be useful, because (as far as I am aware) BigQuery does not support updating the schema of a table (except for the most trivial cases, e.g. required to nullable). So if the new rows changed the table schema, you'd have to reimport the entire dataset into a new version of the table (using the new schema).

Just a quick note: In the absence of further comments, I will be closing this in my next house cleaning sweep.


docs/testing.rst: Fix typo and name of a package.

Remove duplicate words.
Replace futurize by future.

Thanks @sharmaeklavya2!  Merged.


Custom Cert SSL- Handshake Exception not detected

Trying to log into firefly I wasn't able to provide my custom ssl certificate. I know there was some time a few months ago where it worked, but now I get "Unknown error" on a Handshake Exception, even though this switch should catch the HandshakeException and give me the ability to enter my certificate right?
https://github.com/dreautall/waterfly-iii/blob/c9fa7c2f5b7903031a0cf9c00ec60fa52a0a019d/lib/pages/splash.dart#L108
I reinstalled the app with the newest version an the error persists. I'm not sure how else I could enter a certificate (is there a config file somewhere maybe?)

Hi, thanks for the answer, I was using the latest github version (0.3.0-beta)


🐞 docker/cli.#Load is unnecessarily slow

What is the issue?
Several users have reported that loading an image into docker takes a very long time. While part of this is inherent (exporting a tarball and loading it into docker can take up a fair bit of memory+cpu), our implementation relies on a lot of extra copying:

It uses core.#Export to export the tarball to a tmp dir on the local filesystem
Then that gets reloaded back into buildkit with a local import
That local import gets copied (to deal with some cache invalidation issues involving local imports)
The tarball is mounted into a container w/ the docker CLI, where it gets read and transferred to the docker daemon

One initial idea for a more efficient approach would be to re-implement cli.#Load to use a core task that starts the docker cli load command as a subprocess and pipes the buildkit tarball export directly into it. Basically, on these lines, set the io.WriteCloser to the stdin of the load subprocess.

:wave: question.
Does buildx currently follow the same approach? It exports the buildkit output and then it uses the engine Load API to import it?
Just wondering.

Does buildx currently follow the same approach? It exports the buildkit output and then it uses the engine Load API to import it?

This gets a bit more involved as it depends on which driver buildx is using:

If the default docker driver is in use, then all of this is avoided because you aren't using "vanilla" buildkit; it's actually a hybrid buildkit baked into dockerd where the storage backend is adapted to docker's graphdriver (rather than the containerd snapshotter backend used by regular buildkit). While that does avoid the issue here, there are a lot of tradeoffs to using that dockerd-buildkit implementation that make it less appealing.
If one of the other buildx drivers are in use, then you are using regular buildkit (same as what dagger does). In this case, exporting to docker is implemented how I suggest we improve things (pipe directly from the export to docker load). It does not do what we do today where the tarball ends up being copied 3 times before being loaded.

2. f one of the other buildx drivers are in use, then you are using regular buildkit (same as what dagger does). In this case, exporting to docker is implemented how I suggest we improve things (pipe directly from the export to docker load). It does not do what we do today where the tarball ends up being copied 3 times before being loaded.

gotcha.. makes sense.. Seems like this process of exporting <> importing images into the engine to make docker run happy could potentially be annoying for big images. I'm wondering if there's anything Docker could to do to make docker run more friendly to OCI standard images so we don't have to load them into the engine each time.

@sipsma when you return from vacation, can you review this priority with @samalba and see if there is a workaround that we can promote to our users in the meantime while we work on a better fix?

One initial idea for a more efficient approach would be to re-implement cli.#Load to use a core task that starts the docker cli load command as a subprocess and pipes the buildkit tarball export directly into it. Basically, on these lines, set the io.WriteCloser to the stdin of the load subprocess.

That would work great. The only downside (and the reason it's this way in the first place) is cli.#Load is built upon the CLI package and supports whatever cli.#Run supports -- loading to a remote engine, ssh auth through dagger.#Secret, ..
Having a native #Load would imply running docker on the client machine, without container:

#Load will need the machine running dagger to have the docker CLI
Authentication sandboxing is bypassed (e.g. it will use whatever auth the client has, including the host ssh agent)
It will not share the same interface of other cli actions (e.g. take a socket as input)

I see a few paths going forward:

Find fixes for all of the above, somehow
Embrace the fact cli.#Load is very different from other actions (in terms of API but also sandboxing behavior, etc)
Keep cli.#Load as is, provide a "fast" core.#DockerLoad (or similar) on the side, specialized for fast loading images on the local daemon

No matter the option, one remaining challenge to which I don't have an answer is sandboxing (e.g. "client API"). Having an operation directly affect the host goes against the client principle. Perhaps this could somehow be integrated into client? I don't know how /cc @helderco

I'll also add that the real fix here should be on the BuildKit-side, all of these other ideas are just hacks to workaround missing features in BuildKit. They would be pretty large changes though; the ability to mount the result of an export directly in an ExecOp would be perfect, but even just the ability to call export from the Gateway API could help a lot.

I don't think we are currently going to invest effort in optimizing this, so closing for now.


feat(process): when not on master branch, exit with 0 instead of 1

BREAKING CHANGE:
Projects that relied on the old when-not-on-master-exit-1 behaviour should use the new
--post-success [cmd] hook to only run subsequent commands when a release occurs.
ISSUES CLOSED: #38

Coverage remained the same at 92.437% when pulling 7a75dce3accd28f72a5794a7e176dd406daa4e76 on feature/exit-zero-when-not-on-master-branch into d1041c094404459ce79fa070bda63149e74620bd on master.


I can't install mininet in VPS C9

Is it  valid to install mininet in C9 vps
I tried to install it;  but i got error

Please do not abuse the github issue system for random questions.


Add Pusher support

To be able to retrieve market listings, sales and chat messages live.

Fixed with PR #52


EPIC: Support for native database types

Prisma handles values based on core types and best effort implementation as mentioned in this spec: https://github.com/prisma/specs/tree/master/schema#data-types
However, many databases support custom data types like JSON, timestamp without time zone, date, binary formats etc.
Prisma should provide a mechanism to utilize these DB specific primitives.
Related issues:

Custom Long type https://github.com/prisma/lift/issues/94
DateTime scalar https://github.com/prisma/prisma2/issues/255
JSON/JSONB types https://github.com/prisma/photonjs/issues/60
Postgres timestampz https://github.com/prisma/prisma2/issues/552
Query Postgres Table with UUID as ID raises error #479

Possibly related:

Using Prisma enums results in setting DB-level default value #741

Spec issue https://github.com/prisma/specs/issues/119

I would also love to see types for varchar(x), smallint, longtext and so on. If a respective database does not support these types, it should "fallback" to the most appropriate type (i.e., smallint -> int.
In Laravel (PHP) they follow a similar approach as can be seen here in the docs:
https://laravel.com/docs/5.8/migrations#creating-columns
They just map to the "database equivalent of FLOAT" (or whatever).
In the grammars for the database engines (i.e., postgres, mysql, ...) this is handled as follows (example for MediumInteger)
PostgreSQL: https://github.com/laravel/framework/blob/6.x/src/Illuminate/Database/Schema/Grammars/PostgresGrammar.php#L487-L496
MySQL: https://github.com/laravel/framework/blob/6.x/src/Illuminate/Database/Schema/Grammars/MySqlGrammar.php#L501-L510
SQLite: https://github.com/laravel/framework/blob/6.x/src/Illuminate/Database/Schema/Grammars/SQLiteGrammar.php#L484-L493
What do you think?
Can we (community) participate and support you in implementing such Grammars for the different Database Engines? If so, i can surely create such mappings and provide a PR? Would love to contribute to this awesome project!
All the best,
Johannes

@johannesschobel it seems from these grammar files that they still provide common core types, just abstract over them (e.g. jsonb maps to text in sqlite).
Are there grammars that don't implement certain features where the database can't properly store the data type?

In Laravel, you have to write "Migration Files", where you define your database structure. In this migration files, you can add fields and define respective types (i.e., json, string, integer, and so on.. )
You can take a look at how to create a migration here: https://laravel.com/docs/5.8/migrations#creating-columns
The Grammar files i linked above, are some kind of "mapping" for these Laravel types. That means, that laravel, for example, provides types (i.e., json) that may not be supported by your chosen database system (sqlite, mysql, ...). This "mapping" is then handled by the underlying grammar file.
I think, the grammars implement a certain interface where all these Laravel Types are defined and then are implemented in the concrete grammar.. But not sure
I hope this helps?! Do you require further information?

@johannesschobel got it. thanks for clarifying, so in a sense they "upgrade" databases by adding features (e.g. jsonb for sqlite) . This works if all your database clients understand this agreement.
What I was curious about is if Laravel changes the migration API based on the database. So for example, they remove $table->jsonb if you're working with an SQLite database. This is more what we are considering.
We could always add more core datatypes to improve granularity and maybe we should. But it's a tradeoff. More datatypes means more surface area to "upgrade" for other databases. It also means that if we add a new core datatype tomorrow, we'll have to upgrade all datasources to support it.

See this comment https://github.com/prisma/lift/issues/116#issuecomment-537534050 for a case where we could need what is currently one core data type (String) to two database column types (varchar and text) due to database limitations.

Dear @matthewmueller ,
thanks again for your reply on this. In some kind of way, Laravel enables new datatypes for underlying databases, yes. However, from 5.0 till 5.8 version (about 4 years) they did not change those Laravel Types - they only added new features (e.g., $table->json) when features where supported in a stable way from the database engines or can be mapped to "more basic datatypes" (i.e., Text) if no appropriate better type exist.
I really like the Laravel approach, as it - basically - is just an additional mapper / abstraction layer for the database types. This makes it incredibly easy to just add new databases "on the go". Changes to these grammars are quite limited (you can take a look at the git history of such files).
It is debatable, if all features provided by Laravel Grammars should be "ported" or not (i.e., naming conventions for index, ...) or if Prisma just takes the idea of mapping internal types to database specific types. Those grammars could also be extended quite easily if you have the need to specify a convention for naming your index structures...

Further, i don't think, that the Laravel Migration API changed significantly over time. Nevertheless, even if you would change your migration idea, you can still "correct" it in the grammars, right? :laughing:

@johannesschobel Would you prefer these "upgrades" versus a grammar that's specific to the database?
For example, you could also have a grammar that doesn't implement $table->json for SQLite, but does for Postgres. Do you see that being an improvement or a step backwards?

i think, that each specific Grammar (i.e., PostgreSQLGrammar, SQLiteGrammar) should extend a BaseGrammar, which may implement a common interface.
The abstract BaseGrammar could have some "default one-fits-all" mappings. For example, the BaseGrammar could map the Prisma internal datatype JSON by default to a TEXT datatype in the database. However, PostgreSQL offers a "native json support", therefore this "mapping method" may be overwritten in the PostgreSQLGrammar to map it to JSON instead.

@johannesschobel what would you do for very postgres-specific types and extensions like polygon, ipaddress & citext?

I think, i would add some kind of getFallbackType() method in the BaseGrammar which is extended by all other database-specific grammars.
This fallbackType returns, for example text as default type... Of course, this fallback Type can be overwritten for a specific implementation (i.e, the PostgreSQLGrammar may use LargeText as fallbackType, while SQLiteGrammar uses Text).
If, for example, the developer defines IPAddress or Polygon as "Prisma Datatype, and respective Datatype is not defined for the database, i would fallback to the fallbackType. For PostgreSQL this would be LargeText` for example.
At a later point in time, you could just add the getIPAddressType() method to the BaseGrammar or whatever specific grammar and map it to a proper database field type. If, for example, SQLite still does not support geo types, just omit it - it will then fallback to the default..
What do you think?

I like the idea of being able to support underlying native types.
I saw an example of a cool idea somewhere that would provide a lot more flexibility in this regard.
scalar CIText = String @raw("citext")

model User {
  id  String @id
  email CIText
}

I really like this derived type idea. Something to keep in mind when spec'ing.

Internal notes:
Test utils database(s) affected:

https://github.com/prisma/introspection-engine-output/blob/test_utils/test-utils/results/postgresql_public_test_utils_niko-public-1_stderr.log (timestampz)
https://github.com/prisma/introspection-engine-output/blob/test_utils/test-utils/results/postgresql_public_test_utils_sonarqube_stderr.log  (bytea)
https://github.com/prisma/introspection-engine-output/blob/test_utils/test-utils/results/postgresql_public_test_utils_standup-slack-bot_stderr.log (timestampz)

Any news on being able specify DB field lengths?

Hey guys, do you an ETA for this feature, or at least JSON/JSONB in Postgres? Cheers!

Basic Json support has been added with beta.4 and beta.5 - check the release notes for details.

Any news on being able specify DB field lengths?

No. We are aware this is badly needed and are looking into how properly solve this in our context.

@janpio maybe it can be done by introducing new @type midifier like: fieldName  Int @type("bigint")
and since js/ts lackes native types to handle differences between integers, floats, unsigned big integers etc, i think it can only rely on users to guarantee the validity of data type instead of doing automatic type.checking

Just checking if any progress/updates on this? The biggest drawback for me right now is the limitation around the String definition, currently generating varchar(191) on MySQL rather than the text data type mentioned in the docs.

In the last days we looked into this and have reached internal consensus on a proposal.
The proposal is based on the mechanism that a user is decorating a field with an additional attribute that specifies the native data type in the underlying datasource. The attribute is scoped to the underlying datasource by prefixing it with {datasource_name}.{data_type_name}. The scoping is intended for future proofing the schema for support for multiple datasources within one schema.
datasource mydb {
  provider = "postgres"
  url      = "..."
}

model Blog {
  id       Int    @id
  title    String @mydb.VarChar(99)
  someJson Json   @mydb.JSONB
}

Notes:

If the user does not specify a custom type this way the existing default type mapping kicks in.
A user can easily see which data types are used in the client and
which one in the datasource because the combination is spelled out explicitly.
The name of the native type is the Pascal cased version of the original name in the docs of the database. E.g. varchar(x) on Postgres becomes @myb.VarChar(x).
The user needs to know the compatibility of prisma and datasource types. E.g. a String is compatible with @mydb.VarChar(x) and @mydb.Text. But String is not compatible with @mydb.XML. The parser will validate this and error for wrong combinations. The VS Code extension will be to assist with this through auto completion.
A native type always maps to exactly one Prisma data type.
If a datasource with multiple providers is used (e.g. provider = ["sqlite", "postgres"]) an intersection of the native types of the providers is created. Only types that are part of this intersection can be used. This e.g. means that the CiText type for postgres is not available if sqlite is part of the providers as well.

Thanks for writing this up. I'd still suggest we don't require manual type-mapping in the schema. I'd prefer:
datasource mydb {
  provider = "postgres"
  url      = "..."
}

model Blog {
  id       Int              @id
  title    mydb.VarChar(99)
  someJson mydb.Jsonb
}

While the seeing your mapping is certainly nice to have, there are many times when our Prisma type doesn't translate into the generated parameters. For example:
datasource mydb {
  provider = "postgres"
  url      = "..."
}

generator go {
  generator = "prisma-go-client"
}

model Blog {
  id       Int      @id
  createAt DateTime mydb.timeStamp
}

In Go this would map to time.Time, in Javascript this maps to Date. There will always be a mental link you need to make between:
Date => DateTime => @mydb.TimeStamp

I'd suggest we just ask the user to make this link:
Date => mydb.TimeStamp

Tooling can also aid this approach. There can be tooltips that tell you the mapping given the generator.

Which database types are compatible with which prisma types, is something to be figured out anyway, latest when I use the client.
It can be figured out later in the execution / generation, but could also directly be visible in the schema.
That way, things are very explicit and as someone who reads the schema, I directly understand, what maps to what.
In general, I'm always a fan of early feedback in any workflow.
If I as a user early while writing the schema get feedback, e.g. through the VSCode extension, I directly can understand then already how the types map. The extension can also show you, what is available if you e.g. want something compatible with String with autocomplete, which is pretty awesome because that way you might explore db types you didn't even know about.
So the schema in that sense has a self-documenting nature.
As soon as you remove that information from the schema, especially as a new user or just a user who is not familiar with a specific native type, I somehow now need to look that up, open the docs etc. At least for me, it's not always clear which type maps to which.
Afterall the user just needs to learn the mapping of the Prisma type to the language type once and will always understand the schema (even though it looks more verbose).

Another point about this is the mental model.
One of the big advantages of Prisma is the higher abstraction on top of low-level database types.
In my application, I just think about a String, no matter if it's stored as a text or varchar(64) in the database.
Achieving the split between this higher abstraction and native types is of course the big challenge.
By keeping a String as it is in the schema and just providing the "implementation detail" or "storage detail", I can still think about it from the Prisma boundary on as a String, meaning the Prisma interface is still just the good old String that I'm used to.

In general, I'm always a fan of early feedback in any workflow.
If I as a user early while writing the schema get feedback, e.g. through the VSCode extension, I directly can understand then already how the types map. The extension can also show you, what is available if you e.g. want something compatible with String with autocomplete, which is pretty awesome because that way you might explore db types you didn't even know about.
As soon as you remove that information from the schema, especially as a new user or just a user who is not familiar with a specific native type, I somehow now need to look that up, open the docs etc. At least for me, it's not always clear which type maps to which.

The main reason I brought up tooling is because tooling works both ways. For example, you could have faint, but always visible annotations in VSCode that show the mapping. The cool thing here is that you can go a step further and actually map it to your generated client type, not the Prisma type, which is a virtual type over the generated client type.
I'd like us to consider this without tooling. For example, using Notepad. Perhaps unrealistic, but it appropriately illustrates the mental hurdles involved in writing a correct schema with Native types.

In my application, I just think about a String, no matter if it's stored as a text or varchar(64) in the database.

You can still do this. What you can't do is fool yourself into thinking that it's a String when it actually maps to a char.

I agree with Matt. Another straightforward example is the ip type. With Matt's suggestion, you can do:
ip @pg.ip

Which will map the type to a string in js, and to a net.Addr in Go.
However, if we would need to use some data type, we would need to specify a Prisma data type, e.g. String:
ip String @pg.ip

This would work for js, but not for go. It's not a string in go, so String is kinda wrong here.

We could solve this by introducing a new Prisma type, for example IP. However, note that we would need to do this for all custom types we want to support, even if they're just supported by a single database. However, it would still be confusing:
ip IP @pg.IP

You still don't know what it maps to. It would map to net.Addr for go, but for js it would actually just be a string, so one might think "why can't I just use String?".

The plan proposed by @mavilein is the direction we're heading. Unassigning myself as I'm not aware of anymore product work to be done here.

Really excited for this one!
@mavilein How does this proposal deal with types such as geometry (postGIS) ? How do we map them to prisma?

@Hebilicious : Geometry types are not part of this first effort for native types. Supporting those will be a separate effort since those types will also require special client APIs. If you have an opinion on how those APIs should look like feel free to open a separate issue and share your thoughts with us 🙏

Thanks for the discussion everyone. Closing in favor of https://github.com/prisma/prisma/issues/3447

@mavilein which version to support? using v2.6.0 now, found not yet.

@willin The work is still ongoing and the discussion from this issue was summarised on #3447 and that issue is now tracking this

Wonder if I'm missing something, because my timestamptz columns are not working in @prisma/client 2.26.0.
I get:

*** WARNING ***
These fields are not supported by the Prisma Client, because Prisma currently does not support their types.

Model "Info", field: "whenCreated", original data type: "timestamptz"
Model "Info", field: "whenUpdated", original data type: "timestamptz"

can we use Buffer data type for images?

Please open a discussion for this question @poorvi-vaish. Thank you.


Link seems to be missing

In the following paragraph it seems we are missing a link after the word see.
Enable retrieval for modern attachment - use this control to include modern attachments or linked files in the collection for further review; read more about the new searchable field names that are available to group this content, see [document metadata fields in advanced ediscovery]

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

ID: 3dac6d75-9258-1cb4-2eec-1c640cbdfef6
Version Independent ID: abf1c8f8-7b34-578e-32ca-4cb0f877fa79
Content: Add search results to a review set - Microsoft 365 Compliance
Content Source: microsoft-365/compliance/add-data-to-review-set.md
Service: o365-seccomp
GitHub Login: @markjjo
Microsoft Alias: markjjo

@mastood Thanks for the heads up. This link should point to this article: https://docs.microsoft.com/en-us/microsoft-365/compliance/document-metadata-fields-in-advanced-ediscovery?view=o365-worldwide
I will fix the missing link.


Could not resolve 'X' to a package

It seems that there was package lag and I his the disable button too many times for a particular package.
Anyway It looks like I cant enable, install, or uninstall packages anymore.
Here's the console output.
Linter-Pylint: package loaded, ready to get initialized by AtomLinter.
/Users/davidawad/Desktop/Atom.app/Contents/Resources/app.asar/src/package-manager.js:377 Could not resolve 'highlight-selected' to a package path
index.js:56 Window load time: 780ms
index.js:14 Unhandled promise rejection Promise__proto__: Promise[[PromiseStatus]]: "rejected"[[PromiseValue]]: Array[1] with error: Array[1]index.js:14 (anonymous function)
/Users/davidawad/Desktop/Atom.app/Contents/Resources/app.asar/src/package-manager.js:377 Could not resolve 'linter-shellcheck' to a package path
/Users/davidawad/Desktop/Atom.app/Contents/Resources/app.asar/src/package-manager.js:377 Could not resolve 'file-type-icons' to a package path

@DavidAwad can you share the contents of your config.cson and the output of apm list --installed?

Thank you for your issue!
We haven't gotten a response to our questions in our comment https://github.com/atom/atom/issues/7335#issuecomment-119259656. With only the information that is currently in the issue, we don't have enough information to take action. I'm going to close this but don't hesitate to reach out if you have or find the answers we need, we'll be happy to reopen the issue.


Doom package management without Doom

Describe the feature
I love Doom package management (with modules, autoload feature and the CLI) and want to use it for my emacs init which I want to build from the ground up.
However, I don't want Doom specific configurations (those in core-ui, core-projects, core-editor, core-keybinds.. etc) but there doesn't seem to be a way to use Doom without its customizations. It would be great if Doom provides fine control of those configurations like it does of other modules in init.el. Perhaps a "doom-core" module that can be selectively removed.
System information
```
SYSTEM  type       gnu/linux
        config     x86_64-pc-linux-gnu
        shell      /bin/zsh
        uname      Linux 5.4.0-62-generic #70-Ubuntu SMP Tue Jan 12 12:45:47 UTC 2021 x86_64
        path       (~/perl5/bin ~/.cargo/bin ~/.local/share/texlive//bin/x86_64-linux ~/.local/bin ~/.local/opt/llvm/bin /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/games /usr/local/games /snap/bin ~/.local/libexec/emacs/27.1/x86_64-pc-linux-gnu)
EMACS   dir        ~/Work/Projects/dotfiles/emacs/.emacs.d/
        version    27.1
        build      Sep 14, 2020
        buildopts  --prefix=/home/abdo/.local/ --with-json --with-modules --with-harfbuzz --with-compress-install --with-threads --with-included-regex --with-zlib --with-sound=alsa --without-gconf --with-mailutils --with-xft --with-xml2 --with-cairo --with-gconf --with-xwidgets --without-toolkit-scroll-bars 'CFLAGS=-O3 -mtune=native -march=native -fomit-frame-pointer -I/usr/lib/gcc/x86_64-linux-gnu/9/include/ -L/usr/lib/gcc/x86_64-linux-gnu/9'
        features   XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GCONF GSETTINGS GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS LIBSYSTEMD JSON PDUMPER LCMS2 GMP
        traits     (gui server-running)
DOOM    dir        ~/Work/Projects/dotfiles/emacs/.config/doom/
        version    2.0.9
        font       #
        theme      doom-one
        build      HEAD -> develop 2ad1eab6e 2021-01-18 19:59:18 -0500
        elc-files  0
        modules    (:completion ivy :ui doom hl-todo modeline window-select :emacs dired ibuffer undo :checkers spell :tools magit pdf :os tty :lang emacs-lisp (latex +latexmk) markdown yaml :email mu4e :config literate (default +bindings) :my-apps (&user org) (&user org-agenda) (&user email) (&user dired) (&user latex) (&user shell) (&user magit) :my-completion (&user ivy) :my-emacs (&user wind-mgmt) (&user paren))
        packages   ((hungry-delete) (openwith) (origami) (lsp-origami) (el-patch) (explain-pause-mode :disable t) (selectrum) (focus) (ace-jump-mode) (iedit) (aggressive-indent) (eglot) (flyspell-correct))
        unpin      (n/a)
        elpa       (n/a)
```

You can remove these modules from your init.el and include only your own modules that you have written with doom's management facilities.

you can disable any package using the function in your packages.el (package! PACKAGE :disable t) this will disable all of the configuration of these packages as well.
as for disabling core and all of the requisite files. as they are loaded by the init.el you can't feasibly edit them without editing the init.el (which is not recommended). I would recommend first disabling most to all of the modules too see if you get the effect you want but if you find doom still does too much you can read through the source or try to maintain your own fork of doom (This could get messy tho)

Moving much of Doom's core functionality out into modules is planned. So is moving Doom's CLI + package manager to a separate repo. Unfortunately I have a long list of TODOs between then and now, so it'll be some months before I get there, but they won't be forgotten.
Since this issue doesn't present anything immediately actionable, and I'm currently in the process of cleaining up the Github so we use Discourse as our issue tracker, I'll close this, but feel free to follow up here.


How to tell the Clusters to use the VAF in MAF input?

Hi. Thanks for developing and maintaing such a cool tool.
I'm wondering how to tell the Clusters to use the VAFs if the input file is in MAF format.
Thanks.
Lin.

Hi Lin,
The tool will only work with VAFs if the input files are provided in VCF format. Please see the following page on our wiki page for an example of the accepted VCF (with VAFs) format.
https://osf.io/qpmzw/wiki/5. Quick Start Example/
Thanks!
Erik


Large numbers of workload endpoints not getting cleaned up, causing "failed to add route file exists"

We are seeing occasional "failed to add route file exists" errors that keep a pod forever in "ContainerCreating" state.  It looks like kubernetes is trying to create a pod that existed previously but wasn't cleaned up in calico properly. In my case, I got this error creating a pod where the pod didn't exist, but there was an existing workload endpoint in etcd that specified the pod name, namespace, and also the worker node that kubernetes was trying to create the pod on. I was able to work around it by manually deleting the orphan workload endpoint and then trying to create the pod again.  I delete the workload endpoint using: calicoctl delete --workload=<NS>.<POD_NAME> --orchestrator=k8s --node=<NODE_NAME> wep <NAME>
Originally we thought this might be due to https://github.com/projectcalico/cni-plugin/issues/352  but since the workaround is to delete the unneeded WEP, I think this is different.  At the least, since our environments have these orphan WEPs, we need a way to handle this until we can move to a release where this is fixed.  I've started writing a script to programmatically delete orphan WEPs, but want to make sure that there is no use for a WEP that doesn't have a currently running pod.  I don't want to delete a WEP if it could cause a problem.  Note also that I reported this issue months ago in: https://github.com/projectcalico/calico/issues/681  but after investigation closed it because it wasn't causing any problems (we weren't seeing the "failed to add route file exists" error).  There was a doc issue opened from that issue (https://github.com/projectcalico/calico/issues/657), but from what I can tell it hasn't been worked since it was opened, and the latest comment is from 21 days ago
Expected Behavior
I would expect that these workload endpoints would get deleted when the pod goes away, and if something prevents that, then periodically (daily maybe?) calico would run something to clean up orphans.
Current Behavior
These WEPs do not get cleaned up, causing the "failed to add route file exists" errors that keep a pod forever in "ContainerCreating" state.
Steps to Reproduce (for bugs)
I'll work on getting a definitive set of steps to create these orphan WEPs, but until then, just running a kubernetes environment for a few days, maybe killing kubelet or taking network interfaces up and down while deleting pods might do the trick.  You could even look at any existing environments you have, I used the following to see how many orphan WEPs I have compared to kube pods for them (<IP_ADDRESS>/16 is the subnet for our ippool):
Number of pods that are not using host networking: kubectl get pods -o wide --all-namespaces | grep "172\.30\." | wc -l
Number of WEPs: /opt/bin/calicoctl get wep -o wide | grep "172\.30\." | wc -l
Context
This issue is affecting us because it prevents pods from starting successfully, and the only workaround we have is a manual one, listed above
Your Environment

Calico version: 2.1.5 (calico-node running as a systemd service)
Orchestrator version: Kubernetes 1.5.6
Operating System and version: Ubuntu 16.04.2

@bradbehle thanks for raising.
Dumping some thoughts - I think there are two related issues here:
1) The kubelet isn't always able to notify Calico about all pod deletion events.
Since kubernetes 1.6 the kubelet should now call the Calico plugin in most scenarios in order to tear down old workloads - a number of windows have been closed, but not all of them.  The big one that remains is "I've decommissioned a node for good but didn't drain it first".
Like you say, a controller would be a good way to handle the remaining case - we could detect when Pods no longer exist in the k8s API and remove them after a time.  We need to make sure we don't delete a WEP that should be there, so we'll need to be careful, but it should be possible.

"but want to make sure that there is no use for a WEP that doesn't have a currently running pod

There isn't a use for a WEP that doesn't have a currently running Pod.  However, you want to make sure not to delete a WEP for a pod that is in e.g. ContainerCreating state, since the script might race with the CNI plugin and end up in a bad state.
2) The CNI plugin isn't resilient to a route already existing when it attempts to do its route programming.

closed it because it wasn't causing any problems (we weren't seeing the "failed to add route file exists" error)

It's only somewhat recent versions of the CNI plugin which attempt to write the route.  Older versions wouldn't have hit the problem even though the stale WEPs were present.  https://github.com/projectcalico/cni-plugin/pull/358 should fix the route programming failure and will be included in the next CNI plugin release.

@caseydavenport Thanks, that explanation helps a lot.  So just so I know I understand, you're saying that the https://github.com/projectcalico/cni-plugin/pull/358 fix should allow the a route to be written and allow these pods to come up and function properly, even if an existing route is there and a stale WEP is present?

@bradbehle yep that's correct.
The old WEP will be updated by the CNI plugin (ensuring only one WEP exists for a given Pod) and the CNI plugin will be resilient to that route already existing.

Update:

above is still an issue that we'll be looking to fix in the near future probably through a long-lived controller of some sort.

above has a fix which has been merged to master and is included in v2.6.0.

I think the work in progress on the "node (cleanup) controller" is here: https://github.com/projectcalico/kube-controllers/pull/176


https://github.com/bdbaddog/scons/pull/new/add_runtest_to_github

https://github.com/bdbaddog/scons/pull/new/add_runtest_to_github
Contributor Checklist:

[x] I have created a new test or updated the unit tests to cover the new/changed functionality.
[x] I have updated CHANGES.txt (and read the README.rst)
[x] I have updated the appropriate documentation

Fails: os/2 thing I mentioned; test/Dir/Source.py which is one of those regex ones I hate: "those look the same to me"; and the rest are "modern Java" problems.


nixos/journaldriver: import module in top-level module list

Imports the journaldriver module into the top-level NixOS module
list to make it usable without extra work.
This went unnoticed in #42134 (mostly because my setup imports modules
explicitly from pinned versions).
Fixes #50390
Note: This should probably be backported to 18.09 because the module is included there, but not imported.
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

[detached HEAD 5c48901a722] nixos/journaldriver: import module in top-level module list
Author: Vincent Ambo<EMAIL_ADDRESS>Date: Thu Nov 15 10:57:22 2018 +0100
1 file changed, 1 insertion(+)


to run model

please provide code to run model

I am interested in code to run sample input on trained model as you have
shown in demo video with streamlit .
On Wed, 10 Apr, 2024, 15:19 Vu DaoDuc, @.***> wrote:

Hi Ayush11090!
Thank you for bringing up this open issue regarding the code to run the
model. I greatly appreciate your interest in contributing to the project.
To ensure that I address your request effectively, could you please
provide more details regarding the specific code you are referring to? Are
you looking for the code to train the model, or are you interested in code
for running model inference on sample data?
—
Reply to this email directly, view it on GitHub
https://github.com/F1xedbot/RazorBlade/issues/1#issuecomment-2047057827,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A3M3LAJM5LYS4BIOISGDP4TY4UDJVAVCNFSM6AAAAABF7I3EJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBXGA2TOOBSG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

In image "huggingface-razorblade.png" there are six different vulnerability are there given but in implement only 2 are there?


Brush Tool cursor size is not the same as the stroke size

Describe the bug
When selecting a brush and adjusting the size of the brush, the cursor (a circle) does not change size to reflect the brush size.
To Reproduce

Select the default image segmentation template.
Try using the brush tool on the airplanes.
Adjust the size of the brush and try zooming in and out.
The size of the brush cursor does not match the size of the brush, making it very hard to do pixel-perfect brusing.

Expected behavior
The size of the cursor matches the size of the brush.
Screenshots
In this screenshot, the cursor is white and the green annotation is the size of the brush.

Environment (please complete the following information):

OS: Linux
Label Studio Version v1.5.0

Related: https://github.com/heartexlabs/label-studio/issues/1247#issuecomment-928936216


raise RuntimeError('No GPU devices found')

DiffAugment-stylegan2/dnnlib/tflib/custom_ops.py", line 52, in _get_cuda_gpu_arch_string
raise RuntimeError('No GPU devices found')

RuntimeError: No GPU devices found

The GPU in my PC is 3   RTX 2080Ti

what happens?

nvcc: NVIDIA (R) Cuda compiler driver

Copyright (c) 2005-2019 NVIDIA Corporation
Built on Fri_Feb__8_19:08:17_PST_2019
Cuda compilation tools, release 10.1, V10.1.105

Does your tensorflow has GPU support? Please try uninstall tensorflow and then install tensorflow-gpu

not use the " pip install tensorflow-gpu==1.15"

use the conda install ensorflow-gpu==1.15


kW_connection is not working properly

Market models including this measure fail to compute it seems.

Closing in favour of #327.


Prevent main window from being shown when launched at login

All creds to @leo for his helpful hint: https://github.com/wulkano/kap/issues/208#issuecomment-339049228
Fix #208
Closes #209 ping @matheuss (I saw it after I PRd this one, but it's outdated by the looks of it 👍 )

Thanks for moving the comment 👍  I will do it this way in the future. I fixed the extra space so tests should pass now 👍

Looks good :)


BSAPI-18: Update the ERD to proper entity–attribute-relationship (EAR)

Documentation Overview
Summary
The ERD is very confusing and it does not represent the recent code changes.
Objectives

Components: The current ER diagram.
Audience: This will help developers understand how the DB should actually look like.
Format: SVG file type.

Detailed Description
The diagram needs to be updated to entity–attribute-relationship diagram because the current one is very confusing.
Acceptance Criteria

It should display the current tables from the entity classes.
The new ERD will be compared with the entity classes in the entity folder.

Additional Resources

wiki page for EAR

Additional Information

Any other notes like priority, dependencies on other issues, etc.

This issue was also resolved with the last commit 675d71d


ccd2iso: init at 0.3

Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Moved near other cd-dvd tools in all-packages and merged.

Thanks!


Patch to remove Gatekeeper dryrun

Addresses:

https://github.com/open-cluster-management/backlog/issues/18217

/hold to test policy-collection E2E on live cluster

/cherry-pick release-2.4 release-2.3

/cherry-pick release-2.3

/cherry-pick release-2.4

/unhold

/cherry-pick release-2.2


[ISSUE] CI : renovate merged elasticsearch helm chart with breaking changes, and didn't run CI

Describe the issue:
Renovate auto-merged this PR yesterday:
https://github.com/camunda/camunda-platform-helm/pull/1404
which breaks existing tests.  When I look on that PR, the only tests that ran was "Update golden files".
We need to investigate why this is, and make sure that Chart.yaml is included in changes that trigger running our integration tests.
I'm switching back to the other related issue:
https://github.com/camunda/camunda-platform-helm/issues/1410
since it has higher priority.

Actual behavior:

Expected behavior:

How to reproduce:

Logs:

Environment:
Please note: Without the following info, it's hard to resolve the issue and probably it will be closed.

Platform:
Helm CLI version:
Chart version:
Values file:

Fixed by: https://github.com/camunda/camunda-platform-helm/pull/1474