Lack of Node Selectors, Affinity, and Anti-affinity Configurations in Helm Charts

Description:
The APK documentation highlights the product's flexible deployment architecture, emphasizing features like node selectors, affinity, and anti-affinity rules for scheduling pods across various deployment environments, including multi-cluster models for high availability and disaster recovery. These features are crucial for organizations aiming to deploy APK in diverse environments, such as different data centers or cloud platforms. However, upon reviewing the Helm charts provided for APK deployment, I noticed that configurations for node selectors, affinity, and anti-affinity rules are not implemented or templated within the charts. This omission significantly reduces the deployment flexibility and the ability to optimize pod scheduling based on specific cluster architectures or requirements.
Furthermore, my experience highlights a broader issue of non-engagement from the WSO2 team with the community, both on Discord and in response to GitHub issues. This lack of interaction is concerning, especially for users seeking support and clarity on product features and configurations. I have raised concerns through the WSO2 Discord channel in the past but did not receive any response, which is disappointing. I plan to bring up this issue of community engagement, along with the specific concern regarding the Helm charts, in a discussion with Asanka at an upcoming meeting in the Netherlands at the end of March. It is crucial for the success and adoption of WSO2 products that the team responsible for community engagement actively participates in discussions, addresses user concerns, and fosters a collaborative environment.
Suggested Labels:
enhancement, helm, deployment, scheduling
OS, DB, other environment details and versions:

Helm version: 1.0.0 (APP version 1.16.0)

Steps to reproduce:

Review the APK Helm charts for deployment configurations.
Notice the absence of node selector, affinity, and anti-affinity rules in the Helm chart templates.

Feature Request:
I strongly recommend updating the Helm charts to include templates for node selectors, affinity, and anti-affinity rules. This update would ensure that the APK's deployment flexibility, as documented, can be fully realized by users, allowing for more precise pod placement strategies that cater to various operational requirements and deployment models.

Hi @steveliem,
Thank you for your valuable suggestions. Currently, our Helm chart does not support node selectors, affinity, and anti-affinity configurations. We will make sure to update the documentation accordingly. These missing features will be included in the upcoming release.
Regarding community engagement concerns, I appreciate you raising this issue. We understand the importance of community involvement. Internally, we have discussed and developed an action plan to enhance this aspect.
Thank you!
Pubudu.

This is fixed with https://github.com/wso2/apk/pull/2305. Hence closing the issue.


fix(35280): added a fix to trigger on viewable items changed when null or 0 is passed in first elemet

Since currently the check was for null , and that too not === check. So added a check , only for item !== undefined, since null is an assigned value, and we can have null as values in the array for flatlist,
undefined is in absence of any data, hence if its only undefined we should assign falsy to frame variable, since null is an assigned value, sometimes null can be passed to data in the dataset
Hence added a check on top of Sam's previous commit to fix it
UPDATE:
Now after discussing with @NickGerleman , removed the check for item with nullish/undefined.
Now directly frames value is being controlled by _keyExtractor function
This is already an issue https://github.com/facebook/react-native/issues/35280

Summary
Currently in my project, even [0,1] -> didnt trigger onViewableItemsChanged since, it was considered as falsy value,
went to check the node modules code for flatlist, debugged this.
When pulled latest main branch, saw it was partially fixed , but for null as values it wasnt fixed. So added that check .

Changelog
[General] [Fixed] Fix VirtualizedList onViewableItemsChanged won't trigger if first item in data  is null
const frame =
      item !== undefined ? this._frames[this._keyExtractor(item, index, props)]
        : undefined;

  in place of existing which is

const frame =
      item != null ? this._frames[this._keyExtractor(item, index, props)]
        : undefined;

Update:
const frame = this._frames[this._keyExtractor(item, index, props)]
Finally this is the one used for getting frames value

@skinsshark  hey , how should i check this test? this is test_windows.
in my mac, yarn test passes all JS tests.
how to replicate?

@gauravroy1995 np! i reran it because it didn't seem related to your change and it's passing now- there are some internal tests that are failing so i'll take a look at those

@gauravroy1995 unrelated to your changes, a rerun/rebase fixed it, thanks for working on this!


Add tool specific files to .gitignore

I wish people would start using global gitignore files for their environment and stop bloating the gitignore files of each project with crap for various IDEs.

@ADmad I get it but for other projects I commit part of the .idea folder, such as the run configurations. Thus I do not want to globally ignore it.


Feature: add SmartRecruiters Push Profile

This merge will:

add the connector SmartCandidate ( Push profile from HrFlow source to SmartRecruiters)

The tests still don't work for me.
Running test_SmartCandidate, I get this:
self = SmartCandidate(auth=SmartToken(access_token='DCRA1-61a8f1f4baad4497bfc86942f7eaa1a4'), session=<requests.sessions.Sess...74a5', source=Source(key='6d68a20b2dd7c2bfdcb232b9234c38eada0fdcb4')), job_uuid='3696cad0-a9b0-4a40-9cd7-4cc5feb1a509')
data = <map object at 0x7fcfbc900390>

    def push(self, data: Dict[str, Any]):
        self.payload.clear()
        profile = next(data)
        self.payload.update(profile)
        response = self.send_request()
        if response.status_code >= 400:
            raise RuntimeError(
>               "Push profile to SmartRecruiters failed : `{}`".format(response.content)
            )
E           RuntimeError: Push profile to SmartRecruiters failed : `b'{"message":"validation failure","errors":[{"dataPath":"/location/countryCode","message":"String is too long (3 chars), maximum 2"},{"dataPath":"/location/lat","message":"Invalid type: string (expected number)"},{"dataPath":"/location/lng","message":"Invalid type: string (expected number)"},{"dataPath":"/education/0/startDate","message":"Format validation failed (should be in YYYY, YYYY-MM or YYYY-MM-dd format)"},{"dataPath":"/education/0/endDate","message":"Format validation failed (should be in YYYY, YYYY-MM or YYYY-MM-dd format)"},{"dataPath":"/experience/0/startDate","message":"Format validation failed (should be in YYYY, YYYY-MM or YYYY-MM-dd format)"},{"dataPath":"/experience/0/endDate","message":"Format validation failed (should be in YYYY, YYYY-MM or YYYY-MM-dd format)"}]}'`

src/hrflow_connectors/connectors/destinations/smartrecruiters/actions.py:155: RuntimeError

I'm not going to go into a full analysis of the errors, but for the first one, it's normal. The connector sets the CountryCode field to NaN when it requires 2 minimum and maximum characters.
See the doc: https://dev.smartrecruiters.com/customer-api/live-docs/candidate-api/#/candidates/candidates.addToJob
I let you manage the rest.


can not upsert

https://sqlite.org/lang_UPSERT.html
CREATE TABLE vocabulary(word TEXT PRIMARY KEY, count INT DEFAULT 1);
INSERT INTO vocabulary(word) VALUES('jovial')
  ON CONFLICT(word) DO UPDATE SET count=count+1;

lib/sqlite3/database.rb:91:in `initialize': near "ON": syntax error (SQLite3::SQLException)

I met with the same bug in Linux with versions:
SQLite3::VERSION # 1.4.1
SQLite3::SQLITE_VERSION # 3.28.0

The same upsert statement works in:

macOS gem
Linux sqlite commandline

But raises syntax error in gem in Linux.

The "ON CONFLICT" upsert feature was added to upstream sqlite3 in v3.24.0. I can't reproduce what you're describing with a version later than that, specifically trying with v1.5.0.rc1 which uses libsqlite3 v3.39.0.


Fixes issue with Google Sign in exiting early

This fixes the issue that people are having where Google Sign in exits early, initially raised here: https://github.com/invertase/flutter_desktop_webview_auth/issues/50
remcova (https://github.com/remcova) fixed the issue on their local repository, so I've taken a number of their changes and raised a PR here.

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

@andyshephard @pr-Mais @Salakar @russellwheatley
Please approve this PR.

FYI I don't have write access to the repository so this will have to be merged by somebody else.

I realized it was part of a fix from remcova's repo. I was wondering if you would consider adding something other than accessToken and idToken to the AuthResult same as remcova's repo. @andyshephard
And.. Is there anyone can merge it?
@lesnitsky @pr-Mais @Salakar @russellwheatley

bumping this...

I've also updated the dependency version to 0.0.14 and signed the CLA. Is it possible to get this merged in, please?


Stopping the cell crashes the server with uncaught error

Steps to reproduce:

Write/generate Typescript code and run it
Stop the cell from running
result is server crash

screen-capture (17).webm
Result:

@benjreinhart @nichochar just adding try...catch will do the trick I believe. Let me know if you want me to open a PR for this?
const killed = processes.kill(session.id, cell.id);

hey @nichochar , did you get a chance to reproduce this?

#334


Generating Swagger-Blocks based on JSON response?

Hi there,
Can I somehow feed Swagger Blocks (or an associated tool) with a JSON dump of my server's response, and have it magically generate the Ruby for me?
i.e, document backwards -- docs last, based on the response I already have.

First of all, awesome work on ErgoDox EZ ;)
I am not affiliated with this project (I only use it) but I understand what you want to achieve.
To support this, you need to code the part that translate your JSON dump to Swagger::Blocks definitions.
It would be some kind of API documentation generator by examples where you feed JSON examples (route, method, authentication, request, response) and the documentation is produced.
This approach has a lot of challenges and drawbacks, way out of scope of this project IMO.
I used this project for a new API so for me, what would be useful is a DSL on top of Swagger::Blocks and other libs so I only have to define once my API and then:

Controllers are produced automatically (I use Rails controllers).
Views are produced automatically (I use JBuilder).
Tests are produced automatically (I use RSpec).
Documentation is produced automatically (Swagger::Blocks).

That would save me a lot of boilerplate code.
If you're in the same situation, you could try Grape and Grape-Swagger.
Cheers!

I like the ideas here but this issue is definitely out of scope of this project and my limited time in maintaining it. Going to close this as wontfix to keep things clean, but please feel free to comment if any fruitful discussions come up.

Thank you @jodigiordano! Will explore in that direction next time I need Swagger. And thanks for your kind words re the ErgoDox EZ! :) And thanks @fotinakis as well, totally agree with wontfix.


StreamingCommunity Not start video

Source information
StreamingCommunity 13.2
Source language
Italiani
Source new URL
Not changed
Other details
base override URLs fixed, cache cleaned, cookies, WebView data and restarted, movies and series are all visible, but none of them start, please fix streamcommunity.at in a webview work

Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have updated all installed extensions.
[X] I have opened WebView and checked that the source URL is not updated yet.
[X] I will fill out all of the requested information in this form.

So has the domain changed?
Because with the new domain (".care") does the same thing


YouTube Vanced new url

vanced.app has become https://vancedapp.com/

As an aside, if you're using an older version of the updater app that still uses the old domain, you'll have to update it manually.


Update repositories.txt

@ArduinoBot

@ArduinoBot

@ArduinoBot

Closing as duplicate of https://github.com/arduino/library-registry/pull/1357


The vscode breakpoint panel cannot be fully expanded, and the vertical scroll bar is always displayed even with few breakpoints. Is this a bug?

Issue Type: Bug
The vscode breakpoint panel cannot be fully expanded, and the vertical scroll bar is always displayed even with few breakpoints. Is this a bug?

VS Code version: Code - Insiders 1.57.0-insider (54d33cf14cf6c0e86880b5b74a5a3628de42bce9, 2021-05-10T05:15:52.500Z)
OS version: Windows_NT x64 10.0.19041

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz (4 x 2494)

GPU Status
2d_canvas: unavailable_softwaregpu_compositing: disabled_softwaremultiple_raster_threads: enabled_onoop_rasterization: disabled_offopengl: disabled_offrasterization: disabled_softwareskia_renderer: enabled_onvideo_decode: disabled_softwarevulkan: disabled_offwebgl: unavailable_softwarewebgl2: unavailable_software

Load (avg)
undefined

Memory (System)
9.59GB (2.54GB free)

Process Argv

Screen Reader
no

VM
67%

This is working as designed. If you disable horizontal scroll you can not horizontal scroll.
If you enable horizontal scroll, we have to leave space to render it.
Thus closing as no plans to change


Is it possible to add option to split uncorrected regions instead of "trimming" them?

Hi,
I have to confess that I have only used Ratatosk once, but I was just thinking about the option for "trimming". The program GraphAligner (https://github.com/maickrau/GraphAligner) offers something where instead of trimming off the low quality or uncorrected bases/regions that it can "clip" the long reads into say parts (if I understand it correctly with the GraphAligner option --corrected-clipped-out instead of --corrected-out [I think --corrected-out is equivalent to the "trimming" option of Ratasok).

Hi @jelber2,
Could you be more specific into what the clipping is? I couldn't find any description of the option --corrected-clipped-out on the GitHub repo of GraphAligner. My guess is replacing the uncorrected bases with Ns or using upper/lower case characters to distinguish corrected/uncorrected bases.

Yes, you are correct that the current README.md (https://github.com/maickrau/GraphAligner/blob/7644b5dd19788501e7de855b8eb9fd5f52e1359c/README.md) doesn't have this information. I saw it at https://www.biorxiv.org/content/10.1101/810812v1.full.pdf+html
Our pipeline has two modes:
either we output the full reads, keeping uncorrected areas as is; or clipped reads,
which remove the uncorrected areas and split the read into multiple corrected sub-
reads, if needed.

So the first part is --corrected-out and the second part is --corrected-clipped-out
Pretty much from when I use it, --corrected-out has similar read lengths to the original, raw long-reads, and has lower quality scores estimated with yak (https://github.com/lh3/yak) and --corrected-clipped-out has shorter read lengths to the original, raw long-reads, but has higher quality scores estimated than the output from -corrected-out reads.
Also, unitig length distribution of the graph used for correction greatly influences read length and quality of the either --corrected option with GraphAligner. Pretty much I have found that if the unitig lengths are short, then one will get shorter and lower quality corrected reads with GraphAligner, especially in just the --corrected-out mode.
Regarding "masking", I actually think both --corrected modes in GraphAligner softmasks some bases, but I don't know what they represent?

Hey @jelber2,
I actually think there was a mix up in the way I named this option in Ratatosk. If you use the trimming option (currently), it is going to split the reads into multiple smaller reads by removing the uncorrected bases from the reads. It will not only trim the beginning and end of the read. So right now, -t in Ratatosk is the same as --corrected-clipped-out in GraphAligner. I will fix the name of that option in the next Ratatosk release (next week).
Now, I don't advise clipping/splitting the reads after correction in general. As you said, the pros of read clipping is that you get much higher quality for your reads. However, read N50 decreases, sometimes quite significantly, which might penalize all downstream analysis, especially if you intend to do assembly. Also, uncorrected bases are not necessarily "bad" bases.  Often, high complexity regions and very heterozygous sites are left uncorrected. Complex SVs might be tricky too. In my experience, the number of uncorrected regions left is much higher in centromeric and telomeric regions compared to other regions. So in my opinion, uncorrected bases are still better than no bases at all.
I am also not surprised by your observation that unitig length influences read quality. Shorter unitigs usually go in pair with more branching in the graph. More branching there is and more complicated it gets to find the right path for correction. Tandem Repeats usually end up with very branching short unitigs sub-graphs for example. However, I'm a little bit more surprised as to unitig length influences read length.

Well, I could be wrong about the read length part. I haven’t systematically tested that.

Is it possible to allow users a choice in different k-mer lengths than the default k=63? Also, have you tried Ratatosk on PacBio CLR reads? Sorry for the additional question.

No worries.
I can provide an option to play with different k-mer sizes. Ratatosk uses two k-mer sizes for each of the two correction rounds such that k2 >= 2 * k1. By default, k1 = 31 and k2 = 63 in Ratatosk. So if you want to change one k-mer size, you will have to change the other as well.
I never tried Ratatosk on PacBio CLR but I was recently in touch with a couple of people trying out Ratatosk on PacBio reads and they seemed satisfied with their results :)

Okay. If say KmerGenie suggests using a k=50 for “optimum” de novo assembly of short reads, would you still recommend using a k1=50 even though k2=101?

I think this is too long. The thing is that the size k use to build the unitigs of the graph is also the size of anchors between the graph and the long reads before correction. So while a longer k seems to be a good idea to increase unitig contiguity, it also means less exact k-mer matches between the graph and the long reads due to the high error rate of these reads. Better sequencing chemistry or basecalling algorithms would make that possible in the future. In the meantime, I doubt you will be able to use k1 > 31 without degrading the correction results.

Okay, thank you. I didn't think about the k-mer matches between the graph and the long reads.

Okay, based on #8, it seems that you are using k=31 for exact k-mer matches of long reads to graph and k=63 for de novo assembly of the graph.

Hey @jelber2,
Sorry about the delay, I somehow missed your previous message. Indeed, I use k=31 for the first correction pass and k2=63 for the second correction pass (graph construction + anchoring). Using 63-mers for anchoring during the second correction pass is only possible because the first correction pass already lowered down the error rate quite significantly.


Expert mode

This is built upon #15 and must be merged afterwards.  The top nine commits constitute this PR
Problem
Users don't want to see repetitive, implicit and overly technical confirmation screens
Changes
Adds a User/Expert display mode app setting (default User mode)

Hide confirmation fields deemed overly technical or repetitive
Hide authority fields that correspond to the pubkey of the requested signer (signer pubkey not hidden in instances where it is being assigned to an account authority role)

@CriesofCarrots and finally...

Ah yeah good call!  I'd noticed this too and meant to go back and investigate.  I think this is the first time we've had enough interesting settings to change to make the issue obvious :sweat:

Ran through this on device, and the behavior (hiding/showing signer keys) looks good! I haven't finished going through this line-by-line yet; no issues so far. However, I have a couple thoughts/questions on the pre-existing settings menu behavior I wanted to get in front of you sooner:

Both suggestions are in 0f18092 :wink:


details tab

Hi, thanks for the plugin, do you know a way to keep details selected on a actor while playing? Eject from player to debug its not a great solution for me.
I wish I could play with my character and interact with world and see the results without eject.

Seems like a good feature. I'll look into this and see how feasible it is.

Version 1.1 now has a new setting to keep the actor selected when playing or simulating.
Checkout the releases section or the commit at dfe7d295e91ab472206cd824b62dd75fdb14dc58. Update to the Marketplace version has been submitted.


Bower install doesn't include the bootstrap styles

I did the bower install angular-bootstrap-toggle-switch --save but that didn't save the bootstrap style how do I solve this?

Hi Edsardio, I had a similar issue. I manually added the file and linked in my root html file. I noticed my button was around 200px tall if I don't override the height.


"updated upickle, Http4s, Monocle and scalaZ versions"

updated to the latest versions of upickle, Http4S, Monocle and Scalaz, without disabling scalac options. fixes #9

@beloglazov travis build seems to be failing because http4s 0.9.1 is using java 8 https://github.com/http4s/http4s/issues/158
what do you think about upgrading the client's jvm target to java 8 as well?

@beloglazov could you merge this PR so I can check whether it fixes #8? Thanks!

Quick note: if you're not interested in requiring Java 8, http4s v0.8.6 also contains the fix and targets Java 7. However, all future developments on http4s will require at least Java 8.

thanks @bryce-anderson
@beloglazov I think it might be good to move to Java 8 sooner than later given Java 7 reached EOL a few months back now. We should also consider associating this change with at least a minor version increase (0.6.0?) given it will cause compatibility issues for clients.

Sorry guys, I've been away for a week, it took me a while to get to this PR. I'll merge it in once the comments are addressed.
@ermyas I think switching to jdk8 is reasonable at this point.

One note: http4s is on v0.10.0 now but that shouldn't change anything if you do/don't bump the version.

thanks @bryce-anderson i've updated to v0.10.0
@beloglazov comments addressed. Sorry about the earlier formatting changes to the build.sbt, i need to change my auto-formatting config in intellij :-)

@ermyas looks good, thanks!
There are 3 warnings now when you run sbt test (introduced in 862e48883658a94361f392eb38954af4f32fabba, I missed them last time):
[warn] src/test/scala/com/ibm/couchdb/api/DocumentsSpec.scala:281:38: Avoid using null
[warn] src/test/scala/com/ibm/couchdb/api/DocumentsSpec.scala:232:10: Public method must have explicit type
[warn] src/test/scala/com/ibm/couchdb/api/DocumentsSpec.scala:241:10: Public method must have explicit type

Could you please fix them in another PR? :)


feat: adjust styling add signup page

Description

[x] adjust theme mode to "light"
[x] adjust light theme color set
[x] adjust footer and header
[x] add a signup page

Related Issue
relate to #55

Thinking it's ready to merge for the current logic.
If the signup flow or other details need to be modified, then should open another PR for that.

As we are approaching the main launch of TGU and MX rounds can we merge this into a development branch and only merge to main critical fixes?

As we are approaching the main launch of TGU and MX rounds can we merge this into a development branch and only merge to main critical fixes?

yes we could, since I know eth MX has already built their own frontend?


Offline track selection

Hello,
Following the documentation for JavaScript, I'm trying to select for download the desired track depending on its bandwidth.
I've tried with the following code:
player?.configure("offline.trackSelectionCallback", with: "selectTrack")
    @objc func selectTrack(_ tracks: Any) {
        print(tracks)
    }

But ShakaPlayer object returns the following error:
[Error]: "Invalid config, wrong type for .offline.trackSelectionCallback"

Due to that, I tried with several changes in the configuration:
player?.configure("offline.trackSelectionCallback", with: "selectTrack()")
player?.configure("offline.trackSelectionCallback", with: "selectTrack(_:)")
player?.configure("offline.trackSelectionCallback", with: "selectTrack(:)")
Am I doing anything wrong? Is track selection not yet available for iOS?

Embedded doesn't support the track-selection callback.  In general, the configure method can only accept strings and numbers, not functions.  And passing some selector won't work since the value is just forwarded to JavaScript.  We could add this callback to the ShakaPlayerStorageClient object like the progress callback.

Thanks @TheModMaker, that would be awesome!
Any ETA about when it would be available?


Records do not get updated if the parent is not changed

I tried to dig deeper into this and it looks like if you try to update a record without changing the parent, it gets saved twice. This is what happens.
let schema = new Schema(db, {
  author: Model.extend({
    posts: hasMany()
  }),
  post: Model.extend({
    author: belongsTo()
  })
});

let author = schema.create('author');
let post = schema.create('post', { authorId: author.id });

post.update({ title: 'Updated title' });

Once you do this, post.save gets called for the first time. This triggers author.save(), which eventually triggers post.save again, but this time, the post has the old attributes, so the updates does not happen.

This commit is causing the problem -> https://github.com/samselikoff/ember-cli-mirage/commit/85a6ac052f38ffd80f41b6d8e87332a680d33740

I tried to dig deeper into this and it looks like if you try to update a record without changing the parent, it gets saved twice. This is what happens.
let schema = new Schema(db, {
  author: Model.extend({
    posts: hasMany()
  }),
  post: Model.extend({
    author: belongsTo()
  })
});

let author = schema.create('author');
let post = schema.create('post', { authorId: author.id });

post.update({ title: 'Updated title' });

Once you do this, post.save gets called for the first time. This triggers author.save(), which eventually triggers post.save again, but this time, the post has the old attributes, so the updates does not happen.

If I remove the check introduced by https://github.com/samselikoff/ember-cli-mirage/commit/85a6ac052f38ffd80f41b6d8e87332a680d33740, only a single save is called, and it is the post.save.

I'm seeing this too, but it's not 100% of the time. Instead of updating title, I'm updating the relationship, e.g.:
let schema = new Schema(db, {
  author: Model.extend({
    posts: hasMany()
  }),
  post: Model.extend({
    author: belongsTo()
  })
});

let author = schema.create('author');
let secondAuthor = schema.create('author');
let post = schema.create('post', { authorId: author.id });

post.update({ authorId: secondAuthor.id });

I've traced it to https://github.com/samselikoff/ember-cli-mirage/blob/master/addon/orm/model.js#L91-L95
Interestingly, at line 93, this.attrs.authorId === attrs.authorId as it should, but on line 95, after this.save(), that is no longer true and this.attrs.authorId is reverted back.

I think it is because the author has an outdated reference of the posts. So we you update the post, it triggers save for the author, which triggers save for every single of the posts, but they are outdated.
@demsullivan have you tried this branch? It should fix the problem.

Yeah that's my understanding... the weird thing is that it's intermittent. It works sometimes, but not other times. Like there's a race condition somewhere.
I haven't tried the fix, but I will try that shortly, thanks!

Tested with #1208 - unable to reproduce the issue now, so it looks like it's fixed!

I lost track of all the threads, but I believe this bug has been fixed.
I'll close this for now – feel free to ping me and I can reopen if anyone's still having trouble! 😄


fix: #1481 Allow frontend verifying test user accounts in FAM PROD for TEST apps

refs: #1481

Backend IDIM web proxy router will use the IDIM web url based on the given app environment
Router guard for verifying target user need to use the IDIM web url based on app environment

thanks so much Ian!! Really good fix, just a small comment, but looks good to me.


Using touch to create init.zsh file to avoid clobber issues.

Hi, I tried to address the (no)clobber problem in a more simple way. I also added another enviroment variable that points to zgen.zsh itself (I found it useful).

What are the benefits of using touch instead of >!? As far as I know NOCLOBBER works with the latter one.
Also hard coding zgen file name doesn't look right. Perhaps we can use ZGEN="${0}" instead.

I believe using touch makes it easier to avoid the issue with users who have: unsetopt CLOBBER.
Concerning zgen.zsh, what exactly do you mean by ZGEN="${0}"?

What is the conclusion about this merge? My version of zgen already conflicts with upstream. I did this because of the way clobber interfered with the creation of init.zsh. I am however unable to reproduce the problem for the current version of zgen.
Excerpt from zsh docs:
CLOBBER
Allows ‘>’ redirection to truncate existing files, and ‘>>’ to create files. Otherwise ‘>!’ or ‘>|’ must be used to truncate a file, and ‘>>!’ or ‘>>|’ to create a file.

I think >! is a cleaner solution afterall and it seems to work on everyone. I'm closing pr because the zgen-save function got refactored.


Karpenter spot provisioning consolidation not working

Description
Observed Behavior:
We have a single spot provisioner in common, and we want the underutilized nodes to be consolidated into other nodes. However, this is not working

Expected Behavior:
If the existing Spot Instance is underutilized and has enough resources to be consolidated to another node, the Spot node should be removed and the pods in use should be moved to another node.
Actual Behavior:
Lightly used nodes are not consolidated over time.
I'm looking at the spot node events and not sure where the problem is.
$ kubectl describe nodes <spot-node-name>
Events:
  Type    Reason            Age                  From       Message
  ----    ------            ----                 ----       -------
  Normal  Unconsolidatable  31m (x6 over 127m)   karpenter  Can't remove without creating 2 candidates
  Normal  Unconsolidatable  14m (x6 over 3h25m)  karpenter  Can't replace a spot node with a spot node

Reproduction Steps (Please include YAML):
provisioner and deployment , pdb files
# provisioner.yaml(only use)
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: dev-eks-ddocdoc-spot-common
spec:
  consolidation:
    enabled: true
  labels:
    nodegroup-type: ddocdoc-spot
  limits:
    resources:
      cpu: "500"
      memory: 1000Gi
  providerRef:
    name: aws-node-template-spot-common
  requirements:
  - key: karpenter.sh/capacity-type
    operator: In
    values:
    - spot
  - key: kubernetes.io/os
    operator: In
    values:
    - linux
  - key: kubernetes.io/arch
    operator: In
    values:
    - amd64
  - key: topology.kubernetes.io/zone
    operator: In
    values:
    - ap-northeast-2a
    - ap-northeast-2c
  - key: karpenter.k8s.aws/instance-size
    operator: NotIn
    values:
    - nano
    - micro
    - small
    - medium
    - large
    - 9xlrage
    - 12xlarge
    - 18xlarge
    - 24xlarge
  - key: karpenter.k8s.aws/instance-generation
    operator: Gt
    values:
    - "2"
  - key: karpenter.k8s.aws/instance-category
    operator: In
    values:
    - c
  weight: 100

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-spot
spec:
  replicas: 20
  selector:
    matchLabels:
      app.kubernetes.io/name: nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: nginx
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: nginx-spot
          image: nginx:latest
          resources:
            requests:
              cpu: "0.5"
              memory: 500Mi
          lifecycle:
            preStop:
              exec:
                command:
                - sh
                - -c
                - sleep 10
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodegroup-type
                operator: In
                values:
                - ddocdoc-spot
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - nginx
              topologyKey: kubernetes.io/hostname
            weight: 100
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - nginx
              topologyKey: topology.kubernetes.io/zone
            weight: 100
      topologySpreadConstraints:
        - labelSelector:
            matchLabels:
              app: nginx
          maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
        - labelSelector:
            matchLabels:
              app: nginx
          maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway

# pdb.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb-spot
spec:
  minAvailable: 50%
  selector:
    matchLabels:
      provisioner: ddocdoc-spot

Versions:

Chart Version: 0.31.0
Kubernetes Version (kubectl version):  Client Version : v1.26.3
Kubernetes Version : AWS EKS 1.25

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

if PDB is set to minAvailable of 1, why can't it provision this pod on another node (there will be 2 pods temporarily), and then remove this pod and then de-provision the node.

if PDB is set to minAvailable of 1, why can't it provision this pod on another node (there will be 2 pods temporarily), and then remove this pod and then de-provision the node.

Karpenter doesn't create pods.  The ReplicaSet controller won't create this new pod since its configured with 1 replica and it already exists.  You'll need to use a minimum of two replicas if you want to use a minAvailable of 1.

Sorry to sidetrack, but where I can get this tool with the usage/costs output?


Where should lights and clipplanes live

With lights (#94) the current idea is that these are objects that live inside the scene, and apply to all children in that scene (and grandchildren, etc).
Clipping planes have some similarities with lights, as in that they have a position and orientation in the world. I'd like to explore if we can treat lights and clipplanes in the same way. This may make the API simpler. Possibly there are other (future) features that also fall in this category.
I don't think there is much need to set lights per-object, but this need is there for clipping planes:  sometimes you want to clip a single object, to "make space" for other objects, and sometimes you may want to apply the same clipping to a much bigger set of objects.
Ideas
Option 1 - props of Material (what we have now)
We have now more or less copied the approach of ThreeJS: we have Material.clipping_planes and Material.clipping_mode. This only really covers the first individual-object use-case.
(In ThreeJS the renderer has clippingPlanes prop (in addition to Material.clippingPlanes), which covers the use-case of applying the same clipping to multiple objects. This feels odd to me though.)
Option 2 - live in the scene
Make Light and ClipPlane objects participate in the scenegraph. They'd apply to the node they're a child of, as well as any of its children, grant-children, etc. This way, you can set clipplanes on the scene, on individual objects, and on groups of objects.
The lights and clipplanes would also be transformed according to the transforms of the node's they're part of. This can be an advantage or disadvantage :)
One (major) disadvantage of this is that you have to organize the scene graph in a specific way. If the position of an element in the graph determines its visibility, transform, lights, and clipping planes, then you can run into trouble because an element cannot be in multiple places in the graph at the same time.
Option 3 - prop of WorldObject
Like 2, but instead of being a Woldbject, they'd be a property of a WorldObject. That way they can be re-used in multiple places in the scenegraph, and clipping-planes can keep being just tuples.
Other options?
...
cc @brisvag

Option 4 - configuration

Make lights and clipping planes world objects that live in the scene.
Give all world objects a configurable property that lists lights and clipping planes that apply to them. This allows users to control the rendering process.
By default all lights and all clipping planes apply.


chore(renovate): group all non-major and disable rate limit

oops, looks like it is not broken. ref: #342


Draft: Arm64 support

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

@conda-forge-admin, please rerender i

@conda-forge-admin, please rerender


Generators for views/models/controls does not work for ts-app

Easy-Ui5 version:
3.0.1
OS/version:
Windows 10
Browser/version (+device/version):
Chrome
Steps to reproduce the problem:

yo easy-ui5 ts-app
cd com.myorg.myapp/
yo easy-ui5 project newview

What is the expected result?
Module automatically found and yo should continue to ask questions about view to generate
What happens instead?
Screen stuck with message and user cannot do anything:
? To which module do you want to add a view? (Use arrow keys)
Any other information? (attach screenshot if possible)

It seems like you want to combine subgenerators of different plugins (generator-ui5-project and generator-ui5-ts-app).
This is not possible, which is why this fails in your case. The subgenerators (of generator-ui5-project) for new views/models/controls are only supposed to work in projects that were generated which generator-ui5-project.
I'm mentioning @petermuessig here so that he's aware of this thread and might want to consider adding subgenerators to generator-ui5-ts-app as well. Or maybe you want to open a PR to add these features.

Thanks @IObert . My bad, I didn't know the ts-app was a separate plugin. I'll look at that and tweak it for our needs instead. Thanks!


add navigation re generated url block

默认的navigation实现增加url再次自定义

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.qiang.shen seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.


Add David-Kunz/jester to Test section

Checklist:

[x] The plugin is specifically build for Neovim.
[x] The lines end with a .. This is to conform to awesome-list linting and requirements.
[x] It's not already on the list.
[x] It supports treesitter syntax if it's a colorscheme.

Thank you @elijahmanor !


SET_CERTIFICATE.Param1 case is not handled

Param1 is set in https://github.com/DMTF/libspdm/blob/883c31e794ea49b8d4203012e9b1e88d9873e82d/library/spdm_requester_lib/libspdm_req_set_certificate.c#L118-L139 It does not handle the case when Erase is not set. In such a case Param1 is just the slot ID, which ignores the certificate model field.

In addition
 if (spdm_request->header.spdm_version >= SPDM_MESSAGE_VERSION_13) {
     /*And the bit[0~3] of request_attribute must be 0.*/
     if ((request_attribute & SPDM_SET_CERTIFICATE_REQUEST_SLOT_ID_MASK) != 0) {
         return LIBSPDM_STATUS_INVALID_PARAMETER;
     }

is incorrect as the send buffer has already been acquired. This check needs to be before the send buffer has been acquired.

In addition when the function returns LIBSPDM_STATUS_SUCCESS the receive buffer is not released. https://github.com/DMTF/libspdm/blob/883c31e794ea49b8d4203012e9b1e88d9873e82d/library/spdm_requester_lib/libspdm_req_set_certificate.c#L205-L215


tracer: capturing an error causes ERR_UNHANDLED_REJECTION or catching Customer's error

Bug description
The Tracer utility has a feature that allows Customers to annotate a segment by adding error data when an error is thrown while capturing the Lambda handler.
This feature comes from the x-ray sdk for node and is implemented also in the Python version albeit in a slightly different way due to the differences in the underlying SDK.
The current Typescript implementation uses a try/catch block to detect the error.
If the library's code allows the error to bubble up, then an ERR_UNHANDLED_REJECTION is thrown.
If instead the library's code catches the error (current implementation) the library is essentially catching an error thrown in the  Customer's code.
I'd be inclined at not catching a Customer's error, but allowing it to bubble up dirties the stack trace by making it seem that the error was actually thrown by Powertools.
Would like to have a discussion to agree on expected behaviour.
Steps to Reproduce
Reproduction steps in this unit test.
Related issues, RFCs

#107

Pending additional customer's feedback the current implementation of captureLambdaHandler decorator & Middy middleware are as follows:

Decorator adds details about the exception to the current segment, then bubbles it up so that customer's code error is respected.
Middleware adds details about the exception to the current segment, then continues Middy lifecycle to allow for further processing by subsequent middlewares.


Improve regex to support old.reddit domain and user/ posts

Currently user/ links https://www.reddit.com/user/username/comments/abcdef/post_title/ are completely ignored by the extension
Also https://old.reddit.com is ignored by the extension
This PR fixes both issues by adding two OR statements to the regex

Closing in favor of #4


changes for company-profile

TODO: code cleanup and renaming of wip classes

CI: No security warnings found


Add carousel effect in Type of Services section

Kindly assign me this one under Apertre24. Thank you

All done PR Merged


[Feature]: Implement delay to click

Feature description
We are using Chrome recorder, make some small delay adaptions to the recording and export puppeteer Javascript files.
We have to add slight delays to clicks, as a previous input change is processed at the next Angular 'tick' via rxjs, and are not yet available when clicked. (In Chrome recorder and in puppeteer headfull mode we like to see the UI changes, before clicked when replaying a recording).
The exported puppeteer files have a "delay", but puppeteer does not process them as they are not defined in ClickOptions or MouseClickOptions.
https://github.com/puppeteer/puppeteer/blob/main/docs/api/puppeteer.clickoptions.md
As we would like to make as less changes to the exported files; Please implement delay for click.
    {
        const targetPage = page;
        await delay(2000);  <---- have to adapt the puppeteer file and add a delay
        await puppeteer.Locator.race([
            targetPage.locator('::-p-xpath(//*[@data-test=\\".FORM_MAIN.mainInclude.buttonsInclude...validateButton\\"])'),
            targetPage.locator('::-p-text(Validate Request)')
        ])
            .setTimeout(timeout)
            .click({
              delay: 2000,     <---- contained in the exported puppeteer file, but is not interpreted by puppeteer
              offset: {
                x: 57.8499755859375,
                y: 5.5999755859375,
              },
            });
    }

// the used delay function
function delay(milliseconds) {
    return new Promise((resolve) => setTimeout(resolve, milliseconds));
}
    ```

You can see that it's defined here on the MouseClickOptions
And the implementation is here https://github.com/puppeteer/puppeteer/blob/main/packages/puppeteer-core/src/cdp/Input.ts#L450.


arkivmusic web sources

Hi jonaaa20.
Can you create "arkivmusic web sources"?
its best classic music source.
10x.

arkivmusic? I'll think about it. I don't have any time to focus on my script so i can't promise anything.


Retrieve data from backend services through action queue

From #27:

The api frontend should handle many concurrent requests that access the api from HTTP. The complete request (body and HTTP headers) are forwarded to AMQP, using the url/path address a a routing key. The HTTP headers can be used as AMQP message properties.

The processing chain of HTTP/AMQP should be non-blocking on both the api frontend and services. The incoming HTTP requests, relayed AMQP requests, and the AMQP / HTTP responses must be correlated using an identifier. The frontend can keep a queue of HTTP request using the correlation_id to match AMQP responses.

Using two different events to retrieve data provides an easy way to track the response time of a particular service, allowing us to specify auto-scaling criteria on a per-service basis


Using like DirectionsService

In google map api, Route can be generated by DirectionsService.
Could you tell how to do that in this plugin?
thanks.

HI @aguilacontrol
can u please tell explain this line
var route = new Array(my_position);

Before ask to someone, I recommend you search over the internet.
http://www.w3schools.com/js/js_arrays.asp

hi ,
i didnt ask about the array creation.
i need to know what implies "my_position ".

I think the value is just LatLng.
You can get your position using map.getMyLocation()

i got working..

above one was not working for me, following will work fine.
var gRoute = response.routes[0]['overview_path'];
for (var s = 0; s < gRoute.length; s++) {
         route.push(new plugin.google.maps.LatLng(gRoute[s].lat(), gRoute[s].lng()));
 }

map.addPolyline({
                        points: route,
                        color : '#0088FF',
                        width: 6
                    });


Lethal_phase subset

added to lethal phase terms

I didn't add

Declaration(AnnotationProperty(oboInOwl:consider))

or remove

# Annotation Property: obo:IAO_0000589 (OBO foundry unique label)

or move

AnnotationAssertion(rdfs:label obo:IAO_0000589 "OBO Foundry Uniquename"^^xsd:string)
)

So not sure why these things are changed in the diff

None of these are important! Its fine that they appeared. Dont worry.

so can I merge?


Query Valid Images txt

Hi Mate,
May I know who do you generate valid_images.txt. Is it generated automatically with some script or do I've to manually make it.

Hi, it is manually created. This is described in the README: https://github.com/felixchenfy/Realtime-Action-Recognition#data-format


K8s test validation DNS != first service ip

What this PR does / why we need it: Follow-up to pull #546 to add a missing test into validate_test.go that verifies that the validation routine checks that the DNS IP is not the first IP of the service subnet.
Release note:
NONE

@rocketraman,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot


feat(bindings/python): Add layer API for operator

Fix https://github.com/apache/incubator-opendal/issues/3459

Java cases failed for dropbox, let's ignore.


TCP Ingress: invalid memory address or nil pointer dereference

voyager
Image:
appscode/voyager:5.0.0-rc.11
Environment variables:
-
Commands:
-
Args:
run
--v=3
--rbac=false
--cloud-provider=azure
--cloud-config=/etc/kubernetes/azure.json
--ingress-class=
--restrict-to-operator-namespace=false

E0301 12:31:19.143272       1 runtime.go:66] Observed a panic: "invalid memory address or nil pointer dereference" (runtime error: invalid memory address or nil pointer dereference)

---
apiVersion: voyager.appscode.com/v1beta1
kind: Ingress
metadata:
  name: deployment-ingress
  namespace: demo
spec:
  tls:
  - secretName: tls-secret
    hosts:
    - test.com
  rules:
  - host: test.com
    tcp:
      port: '7878'
      backend:
        serviceName: my-nginx
        servicePort: '1883'

The operator is throwing error if the ingress above is deployed shortly after the operator or when the number of pods belonging to the my-nginx service changes. After an error thrown the operator no longer updates the haproxy.conf ConfigMap
This only occurs with if a TCP type Ingress is changing, but it affects HTTP ingresses once the operator has thrown an error.

I've tried a several option, the one that made a difference is without the tls: section, so the problem seems to be related to the TLS termination.

@rzal , what version of Kubernetes are you using? kubectl version

Can you please try with the latest voyager release 6.0.0-rc.2 and see if that fixes the issue?

@tamalsaha

what version of Kubernetes are you using? kubectl version

Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.4", GitCommit:"9befc2b8928a9426501d3bf62f72849d5cbcd5a3", GitTreeState:"clean", BuildDate:"2017-11-20T05:28:34Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.7", GitCommit:"b30876a5539f09684ff9fde266fda10b37738c9c", GitTreeState:"clean", BuildDate:"2018-01-16T21:52:38Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

Thanks, I'll try with the new version later today.

@tamalsaha Everything is working now, there's no sign of errors. Thanks!


Added DaveBhandari.json

Added my name @kunal-kushwaha @darecoder @KeenWarrior @GangaChatrvedi

Thanks @Davekibh for your PR, Welcome to the community.


[Mixpanel] DUOS-2521 User Registration and Sign In

Addresses
Mixpanel implementation
Summary
The latest updates to DUOS-UI includes the addition of Bard's Methods for Mixpanel Calls and Registration and Sign-in events. There was also some minor refactoring done on the SingIn.js file to improve readability.

Have you read Terra's Contributing Guide lately? If not, do that first.

Label PR with a Jira ticket number and include a link to the ticket
Label PR with a security risk modifier [no, low, medium, high]
PR describes scope of changes
Get a minimum of one thumbs worth of review, preferably two if enough team members are available
Get PO sign-off for all non-trivial UI or workflow changes
Verify all tests go green
Test this change deployed correctly and works on dev environment after deployment

The SignIn.js file could use further refactoring.


Kids section not working

Pogo hindi,nick hindi,sonic hindi, discovery kids, history tv 18 not working because all these channels support dual audio please fix !!
if you want audio source for these channels use
https://www.hotstar.eu.org
Open in chrome browser in pc play a dual audio channel eg history tv 18 and press f12 for inspect to open under network tab filter .aac for audio source and .m3u8 for video source
Hoping for next update thanks ☺☺

unable to login there

check the latesh build bro :)


Some simplifications using isnan

Code simplification using isnan defined here:
https://github.com/cupy/cupy/blob/7d18da1918ebe4febd7eaa5896895b957e6a2ba6/cupy/core/include/cupy/complex.cuh#L25-L27.

Jenkins, test this please.

Jenkins CI test (for commit 0a744bbb5d221983a3e22ef875dfc3387094507c, target branch master) failed with status FAILURE.

Jenkins, test this please.

Jenkins CI test (for commit 0a744bbb5d221983a3e22ef875dfc3387094507c, target branch master) succeeded!


Port to TypeScript

See this intro here: http://10consulting.com/2012/10/12/introduction-to-typescript-presentation/
Porting to TypeScript is quite well aligned with the Snowplow tech goal of strongly typed data pipelines.
Unlike CoffeeScript, TS doesn't introduce any of its own design weirdnesses.

See https://github.com/snowplow/snowplow-javascript-tracker/issues/526

We even can publish definition files for stringly-typed method like `snowplow_name_here('trackEvent') https://github.com/DefinitelyTyped/DefinitelyTyped/blob/types-2.0/google.analytics/index.d.ts

Cool idea!

Good opportunity to do this as we move to v3.


Added requirement for ICU Data

As a result of segfaults #10152, #10171

https://github.com/yiisoft/yii2/commit/9d79038485ea4ca79a6137b3d09bb271bc97c9d4

Thank you!

:+1:


[Question] Is there a contribution guide?

I tried to clone the repo and run it on my machine but got several errors.
First error got solved by updating Vite.
Now Vite is running but still having an error on the homepage.
Is there a contribution guide? or an installation steps?
Thanks for the awesome package.

There are no other requirements, you can try use node > 16.

What's the error? Maybe you can remove the package-lock.json and node_modules, then npm install.

@mengxiong10 Thanks, when I removed the package-lock.json node_modules and tried again it worked. I wonder, will the changes in the package-lock.json be accepted?


Using commit_bbl_state_dir encourages committing secrets

There are various credentials in bbl-state.json, .tfstate and deployment vars files. Having commit_bbl_state_dir in bbl-up and bbl-destroy encourages folks to use the git resource for these files. git was not designed to be a secret store. Being one push away from leaking director credentials is... risky.

Hey Jason - thanks for bringing this up. There's a bunch of potential routes to take here and I could spin up a charter for the team to investigate but before doing so, I'd be curious to know your thoughts and ideas about how you'd go about solving this.

The cloudfoundry/bbl-state-resource may suggest an alternate path forward, using storage buckets on GCP.

I'd like to see a flag to disable committing to git, or ideally one to enable it but that would break users.
Right now the error doesn't fail our jobs so it is just a bit of noise. @wfernandes wrote a vault-resource that tarballs up the bbl state dir and crams it into vault. That is how we are managing it.
I fear the git error message encourages using the git-resource to store bbl state dir, which, like I said previously can be risky.
Also, I have heard rumors of bbl supporting storing state securely using something like credhub and not hitting disk. I'm not fully up to speed with that development however.

We don't currently have plans to store state in credhub. Bosh CLI may one day support secret storage during create-env, which would extend to BBL for free, but I don't believe that is under active development.
We do plan to eventually support storage in all major IaaS vendor's blob storage (and already do support it for S3) which would remove the temptation to use Git for this. You still have to opt in, but when opted in your state is always synced with the bucket and won't be on disk (outside of tmp) unless you pull it down.
Wherever you store your state, the critical items for ephemeral/integration/non-PII environments to not store on disk would be the IaaS credentials, which already can be stored in credhub (or Vault) via a Concourse's built in secret management. I think it is redundant to add the configuration and bosh credentials to Vault if you are a CF component team, these should be rotating on a daily basis.

Haven't tried it yet, but what about something like git-crypt/sops? It's still committing to git, but encrypted with gpg keys. Not sure how well it'll work, I'm going to try it out in the next few days, but figure I'd share the idea.

Hi @jasonkeene
We recently made a change to the bbl-up and bbl-destroy tasks to allow users to optionally store the bbl-state as a tarball that can be persisted in S3/GCS/online storage instead of committed to a GH repo. If this is this a suitable solution, could you please close this issue so we know that we don't need to address it further in future?
Thanks,
Dave

^if using s3 for storing state as a tarball, is it possible to consume it as a tarball as input in other tasks?

Hi @aegershman,
Yes. Both s3 and gcs resources support an unpack: true parameter that will unpack a tarball during the get step.
Regards,
Dave

@jasonkeene, Let us know if the last response from Dave solves the issue you described. I am closing due to inactivity but you can always reopen the issue if the problem still persists.


kubectl uses far more memory than expected

We use kubectl in some jobs to check on the cluster.  However, we have found that it can be rather costly in memory use in either small or large clusters.  Even more surprising, getting the results as YAML costs more than twice the memory as getting the results as JSON (even though the YAML output is usually half the size of the JSON output)
What happened:
First, the amount of memory used has gone up over the versions of kubernetes - significant increase in 1.18 vs 1.15 (the prior time I looked).
However, there is obviously something wrong with kubectl since the amount of use is far beyond reasonable.
Using the /usr/bin/time command to measure process resource consumption when doing these commands to a cluster we have and using wc to show the number of characters created in the output we see that the number of characters of yaml output is 479,416,955 and the amount of memory used by kubectl is 4,143,732K (4 gigabytes!) or around 9 times the size of the output!
What is worse is when doing the same with yaml we get noticeably smaller 233,672,375 characters of output (which is due to yaml being far more compact representation) and yet we consume 14,683,072K (yes, 14 gigabytes!) which is almost 70 times as much memory as the output and over 3 times as much memory as producing the same data in JSON!
$ /usr/bin/time -v kubectl get pods --all-namespaces --output json | wc --chars
        Command being timed: "kubectl get pods --all-namespaces --output json"
        User time (seconds): 74.95
        System time (seconds): 1.75
        Percent of CPU this job got: 98%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 1:17.59
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 4143732
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 169
        Minor (reclaiming a frame) page faults: 42114
        Voluntary context switches: 48882
        Involuntary context switches: 2159
        Swaps: 0
        File system inputs: 38976
        File system outputs: 96
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0
479416955

vs
$ /usr/bin/time -v kubectl get pods --all-namespaces --output yaml | wc --chars
        Command being timed: "kubectl get pods --all-namespaces --output yaml"
        User time (seconds): 166.93
        System time (seconds): 16.21
        Percent of CPU this job got: 121%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 2:30.86
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 14683072
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 61
        Minor (reclaiming a frame) page faults: 1607011
        Voluntary context switches: 44447
        Involuntary context switches: 6393
        Swaps: 0
        File system inputs: 4680
        File system outputs: 96
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0
233672375

What you expected to happen:
I would expect that this output would be produced at the most at around 1x of data size since serialization of the fields has a lot of repeated elements (field names) that should not be repeated in memory.
Even worse was the drastic jump in memory consumption based on output format!  Going to 14 Gigabytes of peak RAM use for yaml output!
For contrast, see these two calls (same thing) to a much, much smaller cluster:
JSON output size: 3,385,403 while RAM used is 69,528K
YAML output size: 1,608,293 while RAM used is 182,472K
The YAML output is nearly 3 times the memory used by the kubectl process (and again 1/2 the output size)
$ /usr/bin/time -v kubectl get pods --all-namespaces --output json | wc --chars
        Command being timed: "kubectl get pods --all-namespaces --output json"
        User time (seconds): 0.69
        System time (seconds): 0.02
        Percent of CPU this job got: 108%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.67
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 69528
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 7
        Minor (reclaiming a frame) page faults: 1530
        Voluntary context switches: 1115
        Involuntary context switches: 81
        Swaps: 0
        File system inputs: 1064
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0
3385403

vs
$ /usr/bin/time -v kubectl get pods --all-namespaces --output yaml | wc --chars
        Command being timed: "kubectl get pods --all-namespaces --output yaml"
        User time (seconds): 1.36
        System time (seconds): 0.13
        Percent of CPU this job got: 129%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.15
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 182472
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 7
        Minor (reclaiming a frame) page faults: 2616
        Voluntary context switches: 1058
        Involuntary context switches: 72
        Swaps: 0
        File system inputs: 1224
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0
1608293

How to reproduce it (as minimally and precisely as possible):
See above - the cluster above is not tiny - this effect is much more impactful on larger clusters but even on small clusters the memory consumption is far larger than the size of the data.
Anything else we need to know?:
We have small periodic jobs that use the kubectl API to do some work.  We like the abstraction this gives us from the underlying APIs for these higher level jobs.  They have also worked across Kubernetes versions, other than the resource requirements.
We had already switched to json output and processing due to kubectl's large memory footprint for yaml but have again hit issues with the large memory footprint (over 4GB just for kubectl process).
Environment:

Kubernetes 1.18.6 and kubectl 1.18.6

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-15T16:58:53Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-15T19:08:46Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}

Running in Azure

OS Ubuntu 18.04.5 LTS (workstation and all cluster VMs)

@Michael-Sinz thanks for reporting!
I have a feeling this is related to https://github.com/kubernetes/kubectl/issues/866.
For triage sake could you please test this with v1.19.3 and the v1.20 beta since you have access to a large cluster?
https://storage.googleapis.com/kubernetes-release/release/v1.19.3/bin/linux/amd64/kubectl
https://storage.googleapis.com/kubernetes-release/release/v1.20.0-beta.1/bin/linux/amd64/kubectl

A quick test (will do more tomorrow) shows that 1.20.0-beta.1 is actually slightly more memory use (very small) but I need to get access to the large production clusters to do a full verification as it is after business hours now and things are scaling down from their peak usage.  (We see 4x to 10x scale variation from low to high during the day.)

I have run the 1.20.0-beta.1 and 1.19.3 now against a large cluster.   Note that the cluster is rather dynamic so the runs are not of the exact same state across the runs.  I also could not complete the yaml output as 1.20.0-beta.1 ran out of memory on my access VM (which has 16GBytes of RAM).
In json it does complete but it is still over 9x the memory compared to the output.  (7.3GBytes of RSS for 781MBytes of output in json)
$ /usr/bin/time -v ./kubectl-1.20.0-beta.1 get pods --all-namespaces -o json | wc --chars
	Command being timed: "./kubectl-1.20.0-beta.1 get pods --all-namespaces -o json"
	User time (seconds): 111.33
	System time (seconds): 4.89
	Percent of CPU this job got: 93%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 2:04.61
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 7367652
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 253
	Minor (reclaiming a frame) page faults: 74874
	Voluntary context switches: 130416
	Involuntary context switches: 3827
	Swaps: 0
	File system inputs: 68680
	File system outputs: 1440
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0
781719220

However, based on minor testing, it seems that 1.20 is better than 1.19:
$ /usr/bin/time -v ./kubectl-1.19.3 get pods --all-namespaces -o json | wc --chars
	Command being timed: "./kubectl-1.19.3 get pods --all-namespaces -o json"
	User time (seconds): 109.72
	System time (seconds): 4.85
	Percent of CPU this job got: 82%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 2:18.09
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 7662328
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 254
	Minor (reclaiming a frame) page faults: 77365
	Voluntary context switches: 117720
	Involuntary context switches: 2963
	Swaps: 0
	File system inputs: 65032
	File system outputs: 1440
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0
779475036

Just for comparison, the kubectl 1.18.6 run against the cluster.  Note that it seems to use less memory than 1.19 or 1.20 (but, again, conditions continue to change in the cluster.  I would look at output size vs RSS used as a measure at this scale)
$ /usr/bin/time -v kubectl get pods --all-namespaces -o json | wc --chars
	Command being timed: "kubectl get pods --all-namespaces -o json"
	User time (seconds): 119.21
	System time (seconds): 2.91
	Percent of CPU this job got: 92%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 2:11.32
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 6952484
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 38
	Minor (reclaiming a frame) page faults: 60523
	Voluntary context switches: 81172
	Involuntary context switches: 2872
	Swaps: 0
	File system inputs: 6184
	File system outputs: 96
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0
757897460

This came up in our sig-cli meeting today.
This might be addressed by not sorting the data or streaming the output as it comes in.
We currently toss everything into a kind: List which is a type of mixed resources. This wasn't really intended to be used externally (#984).
/triage accepted
/priority backlog

I do find it interesting that the memory use is so far more than the size of the JSON (and even worse, the YAML - still unclear how we can used that much more memory just because the output is YAML)
While the kind: List may be a part of this, I think the bigger problem is more fundamental.

As far as I know, this issue is still live - the amount of memory used to get the complete pod status of the cluster is amazingly large for non-trivial clusters.  Far more than expected given the size of the (rather verbose) json formatted output.
/remove-lifecycle stale

@Michael-Sinz turns out we have some profiling built-in to kubectl.
Cant you please run the following and upload the dumps?
kubectl get pods -A --profile allocs --profile-output allocs-plain.pprof > /dev/null
kubectl get pods -A --profile heap --profile-output heap-plain.pprof > /dev/null
kubectl get pods -A --profile cpu --profile-output cpu-plain.pprof > /dev/null

kubectl get pods -A -o json --profile allocs --profile-output allocs-json.pprof > /dev/null
kubectl get pods -A -o json --profile heap --profile-output heap-json.pprof > /dev/null
kubectl get pods -A -o json --profile cpu --profile-output cpu-json.pprof > /dev/null

kubectl get pods -A -o yaml --profile allocs --profile-output allocs-yaml.pprof > /dev/null
kubectl get pods -A -o yaml --profile heap --profile-output heap-yaml.pprof > /dev/null
kubectl get pods -A -o yaml --profile cpu --profile-output cpu-yaml.pprof > /dev/null

If you want to take a peak at what you're uploading you can run go tool pprof -top allocs-json.pprof.

I will have to see what I can poke at.  I assume no details about the cluster will be in the profile reports, right?
(I will take a look at the code in a bit)
I may not have the same size cluster available right now - we dynamically scale rather drastically all the time (up and down) so the overall scale of the cluster changes.  (In addition to moving various workloads between different clusters)
But I should have some interesting files to post soon.

I assume no details about the cluster will be in the profile reports, right?

From what I can tell.
Source.
Here's the proto it writes out.

Note that our clusters are relatively dynamic so I can not assure you that the same state exists across all of the runs.
I did two clusters - a smaller one and a larger one.  The larger one took a long time to complete and I had to use an different machine to run the test on it as the memory use was too high for my normal dev VM.  (It literally was OOM killed by the kernel on my regular dev VM)
I hope the data provides what you need.  A quick look at the allocs shows a major cost for yaml.  Almost like it produces the json in memory and then produces the yaml.

This is correct - in Kubernetes yaml is produced by translation from json.
Ironic, for a system that has so many complaints about yaml, that it never actually uses it internally.
Note that Go will typically make a heap twice as big as it needs for your data; you can adjust this with the GOGC environment variable but only so far.
I tend to agree that #866 is the real underlying problem.

I think #866 is part of the problem but there must be some serious inefficiencies when even the textual form of json (which is rather verbose and indented/etc) is many times smaller than the memory needed to produce it.  Something very wrong is going on when that is the case.  (Not to mention that the yaml is a translation of the json and not a serialization of the same objects that produced the json - I don't really care since I can consume the json just as well as the yaml)
RAM used: 6,952,484K  Size of json output:  757,897K
Where is the extra memory being used?  Even if this is 2x the actual used, we are still at 3,476,242K of memory used.  Where did that extra 2.4GB of RAM get used over the text form of the json data?  How much additional data or structures would be needed to do this given the fact that the json has so much redundant data in it due to the k:v syntax.

there must be some serious inefficiencies when even the textual form of json (which is rather verbose and indented/etc) is many times smaller than the memory needed to produce it

that's not surprising at all. a json map can be represented in two bytes: {}. an empty map[string]interface{} allocation takes much more memory than that.

/remove-lifecycle rotten

/remove-lifecycle rotten

Any updates on this issue? I've run into this problem as well. Getting ~600 resources within a namespace uses 400MB, the resulting yaml is 22MB, json is 31MB.
Only getting the names and then separately getting each manifest will take too long, so that isn't an option.

/help

It looks as though this commit: https://github.com/kubernetes/kubernetes/commit/07d2da75bd6b5a0bd9b4618889ba1a42ad192b03 fixed this issue for k8s versions 1.29 and above. The commit upgrades openapi from v2 to v3 for client side apply. I haven't done a thorough check on whether it resolves for other client side commands though.


Add tutorial

Add tutorial similar to that in Ren'Py.

Tutorials are published in Docs https://rakugo.readthedocs.io/en/latest now - closing this.


Advanced Tab Settings

No libbitcoin info for new type of multiple server connection (encrypted)
Disable Visual Effects helper text messed up

I can't replicate the text alignment issue. Can someone with a Mac confirm whether this is showing up on OSX?

I could replicate it on OSX. I'll fix it, please post a screenshot of what it's suppose to look like.

It should be vertically centered.

It may be a float issue, making the text smaller, two lines, or removing some text may fix it.

Removing some text will only fix it for English. It should be 2 lines instead. I'll look into it.


Deletes Promoted flag for real

dosomething_reportback_update_7019 never ended up deleting the Promoted flag, and I missed it. The issue seems to be because the Image Description field was never properly deleted from the Promoted flag.
This PR adds a new hook, dosomething_reportback_update_7020, which basically is identical to 7019 except it deletes the Image Description field correctly, allowing the Promoted flag to be deleted.  This is pretty gross but manually changing the schema in the DB doesn't feel like the right way to handle either...
What do you think @sergii-tkachenko ?

:+1:


Include k8s node name in emitted events

Is your feature request related to a problem? Please describe.
It is unclear from an event in v0.0.16-alpha which node saw a particular HTTP event. We've got source and destination IPs (and maybe pod names if those IPs map to pods), but there's no node identifier.
Describe the solution you'd like
Describe alternatives you've considered
Additional context

Fixed in #224


Link text background color when pressed

Hey again.
I've set a custom view to a dialog via .customView which contains a couple of different TextViews.
One of them has <a> links in its string resource, and although the links work just fine, they don't give any visual feedback, like a highlighted background color, when tapped.
It behaves as expected in a normal TextView in a layout though.
Perhaps this is a bug?
BTW, I call setMovementMethod(LinkMovementMethod.get instance()) on the TextView.

This isn't an issue with the material-dialogs


Naming/AccessorMethodName could be more tunable

Hi!
Is your feature request related to a problem? Please describe.
We have a method named get_min!.  It has a bang because it's not just an accessor: it has side-effects (and does return a result).
I think that Naming/AccessorMethodName should not fire in this case (names ending with a bang).
We also have other get_foo methods, where we use get_ as a hint that they are costly.  They are not just as cheap as accessors.  It would be nice if Naming/AccessorMethodName had some AllowedMethods or AllowedNames support for such cases.
Describe alternatives you've considered
Of course we can use # rubocop:disable, but:

for get_min!, it does not look like a genuine accessor, IMHO it should not fire at all
for other the cases, it's just nicer to avoid cluttering the source with magic comments, but it's also less precise (it is project-wise), so I can see reason to reject this.

Thanks!

Personally I have used fetch in these cases. Maybe because of the constraints the cop imposes but I also feel like that communicates more clearly that the method is doing more than meets the eye. Not a native speaker though.
For !, docs https://docs.rubocop.org/rubocop/cops_naming.html#namingaccessormethodname already have a note about the expected arity and I don't think it would be that big of a stretch to expand that to bang methods since it also doesn't look like a tradition accessor. Though I also don't see the problem in just following the cop here.

Names ending with ! or ? are not appropriate as attribute names, so it seems reasonable to allow them. I opened #13151. However, considering the role of this cop, I'm still uncertain about the appropriateness of having an allow list.

This is fine by me.  @Earlopain 's suggestion for fetch is nice, we will probably move to it.  Thanks to both of you.


sinatra-logger does not overide sinatra's inbuilt logger

C:/Ruby26-x64/lib/ruby/gems/2.6.0/gems/sinatra-<IP_ADDRESS>/lib/sinatra/base.rb:329
    require 'sinatra/logger'

    COOKIE_SECRET = SecureRandom.hex(64).to_s
    # The main app
    class Logbook < Sinatra::Base
      logger filename: "log/#{settings.environment}.log", level: :trace

produces a "one extra argument found requires 0" error. on the logger line in rubymine.

ive added it and installed it in bundler as perscribed but it does not allow me to use the new logger

https://stackoverflow.com/questions/5995854/logging-in-sinatra
im using the mentioned version and i guess we do need to setup the logger differently using use.

i will now attempt to plumb in using the use function.

i couldnt get it to work, but someone more studied could do it maybe.


Warn when uncalled timers on uninstall

A good test doesn't mock more than it needs to. Thus I would expect that when I call clock.uninstall() there would be no uncalled timers left.
Yet sometimes I suck at writing tests and would have a false positive / negative, or even worse, a silent error dangling in a setImmediate that never got called.
It would be tremendously helpful if we could log a warning (or throw) when there are uncalled timer functions. Either by default, or as an option.

I can start working on this if you'd like, basically the logic is:
If uninstall is called and clock.timers.length > 0 then emit a console.warn.
What behavior would you prefer @fatso83 ?

Throw on timers remaining?
Warn on timers remaining?
Ignore on timers remaining? (Current behavior).

I'll also run the change on the Peer5 tests that use lolex (about 300) and see how it affects them.

Could be a three-option setting ("ignore", "error", "warn"), where we could set a new default. A lot of people don't like console statements filling up their tests, but then they at least have the option of turning it off.
I am not totally sure what would be a good default here. Maybe @mroderick could chime in with an opinion.

@fatso83 we could process.warn on Node and throw in browsers - although lolex is used in tests so I doubt it would cause availability issues.
I'm :+1: on throwing everywhere in terms of design - but it would be a breaking change. I'm also fine with ignoring by default if NODE_ENV is production and warn otherwise.

Also agree with throwing as a general rule of thumb. But as we shipped 2.0.0 a few days back, it's a bit early for making a new breaking change - warranting a new major version. We could do this as a stepwise refinement, kind of the way we deprecate things in Sinon:

Current major version: print warning about non-optimal current design
Next major version: Throw error

I'm 👍 on throwing everywhere in terms of design - but it would be a big breaking change. I'm also fine with ignoring by default if NODE_ENV is production and warn otherwise.

I am with you for throwing. I think @fatso83's suggestion is reasonable!

So, I completely changed my mind on this after writing the PR, it turns out writing setInterval and but not calling clearInterval is a pretty common scenario. Another common scenario is doing a setTimeout and checking it was not called after a duration - a clearTimeout is not used.
To illustrate this - lolex's own test suite emitted 20 warnings for tests like:
it("creates updated Date while ticking", function () {
            var spy = sinon.spy();

            this.clock.setInterval(function () {
                spy(new Date().getTime());
            }, 10);

            this.clock.tick(100);
            ...

Both lolex's own test suite and our own tests at Peer5 emitted multiple warnings.
I am now convinced the right thing is to not do anything if there are remaining timers and the clock is uninstalled. We might want to consider having uninstall returning a list of remaining timers.

If anyone wants to play with it themselves:
diff --git a/src/lolex-src.js b/src/lolex-src.js
index 0918420..e76f063 100644
@@ -348,6 +348,24 @@ function clearTimer(clock, timerId, ttype) {
     }
 }

+function warnOnPendingTimers(clock) {
+    if (firstTimer(clock)) {
+        var modernNode = global.process && typeof global.process.emitWarning === "function";
+        var hasConsole = global.console && typeof global.console.warn === "function";
+        var warningMessage = "lolex was uninstalled but there are still active fake timers";
+
+        if (modernNode) {
+            process.emitWarning(warningMessage, {
+                type: "DeprecationWarning",
+                detail: clock.timers
+            });
+        } else if (hasConsole) {
+            /* eslint no-console : "off" */
+            console.warn(warningMessage, clock.timers);
+        }
+    }
+}
+
 function uninstall(clock, target, config) {
     var method,
         i,
@@ -372,6 +390,9 @@ function uninstall(clock, target, config) {
         }
     }

+    // Warn if there are unexecuted lolex timers when uninstalling
+    warnOnPendingTimers(clock);
+
     // Prevent multiple executions which will completely remove these props
     clock.methods = [];
 }

Good points you raise there, Benjamin. I guess we could still supply throwing an exception as a feature that can be toggled on (off by default). I also like that uninstall could return the timers. Maybe it would return a structured object of some kind like { setTimeout: [], setInterval: [], ...}. Not sure how easy this would be to implement, though.

We might want to consider having uninstall returning a list of remaining timers

That seems reasonable

With @benjamingr's code I think this is a low-hanging fruit to implement. Added a better title for clarity.

I can pick this up

Can't self assign, feel free to assign me and I'll take a stab tomorrow.

@Moeriki I know it's been a year - but would love your feedback on the solution proposed in https://github.com/sinonjs/lolex/pull/141 and discussed here

I rarely use Lolex anymore so it's hard to consider my previous use-case. That said returning a list of timers on uninstall seems like a safe way to resolve this issue.
Let users assert the remaining timers themselves. Flexible 💪 and easy to reason  about. I like it. 👍


Re-enable Window covers

Yes after it was tested by users for 2 or 3 weeks and there are no problems with it

Okay. Fine for me. That's the usual way.
P:S: May you  please create the npm package for this version - I have no permissions to do that.

already done


cmd/compile: optimize convI2I, assertI2I, assertE2I for statically known types

A conversion that involves runtime.getitab (convI2I, assertI2I, assertE2I) is generally much slower than an ordinary
interface value construction from a statically known concrete type.
this is fast:        *bytes.Buffer => io.Writer
this is not as fast: io.ReadWriter => io.Writer

The Go compiler has an IR-based devirtualization pass that performs a local method call devirtualization. It's not as silly as it might sound as it works well enough in some situations thanks to the inlining.
It does not, however, handle I2I-like operations. Even if we know that converted value has some non-interface type T, we still do an expensive I2I operation.
This situation occurs a lot in a codebase that works with hierarchical data. AST is an example: we have ast.Node and ast.Expr. It's quite common to write a function that accepts ast.Node while some other function can operate with ast.Expr. In the *ast.Ident -> ast.Expr -> ast.Node chain we can simplify the ast.Expr -> ast.Node conversion if we use the information that ast.Expr is actually *ast.Ident.
A real-world case can be found in the Go compiler code.
func (p *noder) structType(expr *syntax.StructType) ir.Node {
	// ...
	p.setlineno(expr) // setlineno is inlined
	// ...
}

func (p *noder) setlineno(n syntax.Node) {
	if n != nil {
		base.Pos = p.pos(n) // convI2I: node->poser
	}
}

// This functions can't be inlined.
func (m *posMap) pos(p poser) src.XPos { return m.makeXPos(p.Pos()) }

Another situation is when constructor returns an interface type, like hash.Hash and then they're passed as io.Writer. In many cases we can avoid convI2I for md5.New() -> io.Writer case (it works for most hash/crypto related constructors).
Here is a simple benchmark that illustrates the performance problem with I2I:
package benchtest

import (
	"bytes"
	"io"
	"testing"
)

//go:noinline
func sinkWriter(io.Writer) {}

func BenchmarkDevirt(b *testing.B) {
	buf := &bytes.Buffer{}
	var rw io.ReadWriter = buf
	for i := 0; i < b.N; i++ {
		sinkWriter(rw) // convI2I
	}
}

If we rewrite convI2I like this (pseudo-code):
convI2I(rw, "io.Writer") -> convI2I(rw.(*bytes.Buffer), "io.Writer")

Then we get these results:
name      old time/op  new time/op  delta
Devirt-8  11.1ns ± 1%   2.4ns ± 1%  -78.55%  (p=0.000 n=10+10)

The same idea applies to the type assertions that involve interface-to-interface conversion.
The optimized code is also usually smaller from the machine code point of view.
.text segment size differences:
go tool: -224 bytes
cmd/asm: -192 bytes

Total binary size differences:
go tool: -543 bytes
cmd/asm: -310 bytes

In general, this is not a binary size optimization as convI2I is quite rare on its own.
There are even fewer cases that we can optimize at the compile time.
I provided these numbers just to be sure that we cover the binary size impact as well.

Note: this does not solve all convI2I issues, but it can at least reduce the amount of convI2I we see in our CPU profiles.
I'll send a CL that provides my first attempt at this optimization. If CL is not good enough, we can at least have this issue that has some sweet numbers to think about.
Implementation notes
Changing devirtualize.go from ir.VisitList to ir.EditChildren makes it measurably slower.
This is why a slightly less simple approach is used when we keep ir.VisitList, but handle some nodes via their parents. It covers less code, but in practice the optimization coverage should be OK. Suggestions are welcome: it could be the case that we can introduce these optimizations to some other part of the compiler.
This approach runs with almost identical speed, compilebench shows no significant diff this time:
name                      old time/op       new time/op       delta
Template                        411ms ± 2%        410ms ± 1%    ~     (p=1.000 n=5+5)
Unicode                         212ms ± 4%        210ms ± 3%    ~     (p=0.310 n=5+5)
GoTypes                         2.18s ± 1%        2.20s ± 7%    ~     (p=0.841 n=5+5)
Compiler                        166ms ± 2%        160ms ± 4%  -3.90%  (p=0.008 n=5+5)
SSA                             16.9s ± 2%        17.1s ± 0%    ~     (p=0.151 n=5+5)
Flate                           263ms ± 2%        261ms ± 3%    ~     (p=0.548 n=5+5)
GoParser                        467ms ± 1%        461ms ± 2%    ~     (p=0.095 n=5+5)
Tar                             351ms ± 2%        352ms ± 2%    ~     (p=1.000 n=5+5)
XML                             459ms ± 1%        462ms ± 1%    ~     (p=0.151 n=5+5)
LinkCompiler                    783ms ± 2%        778ms ± 2%    ~     (p=0.730 n=5+4)
ExternalLinkCompiler            2.56s ± 0%        2.58s ± 2%    ~     (p=0.413 n=4+5)
LinkWithoutDebugCompiler        480ms ± 2%        477ms ± 3%    ~     (p=0.690 n=5+5)
[Geo mean]                      683ms             680ms       -0.40%

name                      old user-time/op  new user-time/op  delta
Template                        532ms ± 2%        514ms ± 8%    ~     (p=0.151 n=5+5)
Unicode                         275ms ±12%        280ms ± 9%    ~     (p=0.841 n=5+5)
GoTypes                         2.84s ± 1%        2.85s ± 5%    ~     (p=0.841 n=5+5)
Compiler                        211ms ± 6%        212ms ± 6%    ~     (p=0.841 n=5+5)
SSA                             23.5s ± 1%        23.9s ± 1%    ~     (p=0.095 n=5+5)
Flate                           328ms ± 5%        333ms ± 5%    ~     (p=0.548 n=5+5)
GoParser                        571ms ± 0%        567ms ± 1%    ~     (p=0.222 n=5+5)
Tar                             442ms ± 6%        433ms ± 4%    ~     (p=0.548 n=5+5)
XML                             582ms ± 3%        589ms ± 3%    ~     (p=0.421 n=5+5)
LinkCompiler                    1.34s ± 4%        1.36s ±10%    ~     (p=0.690 n=5+5)
ExternalLinkCompiler            2.91s ± 3%        2.91s ± 1%    ~     (p=1.000 n=5+5)
LinkWithoutDebugCompiler        614ms ± 3%        615ms ± 3%    ~     (p=1.000 n=5+5)
[Geo mean]                      887ms             889ms       +0.19%

Just want to drop by and thank you for writing this issue with such detail and in a way that most Go developers can understand :)


drivers-one-shot is not ready yet. Please wait for a moment!

Short summary about the issue/question:
I followed the step while using installed driver server, and my service-configuration.yaml is like this:
drivers:
  set-nvidia-runtime: false
  version: "418.56"
  pre-installed-nvidia-path: /usr/lib/nvidia-418

the k8s dashboard:

the driver docker log:
+ export MLNX_PREFIX=/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode
+ MLNX_PREFIX=/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode
+ export NV_DRIVER=/var/drivers/nvidia/418.56
+ NV_DRIVER=/var/drivers/nvidia/418.56
+ export LIBRARY_PATH=/usr/local/cuda/lib64/stubs:/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/lib
+ LIBRARY_PATH=/usr/local/cuda/lib64/stubs:/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/lib
+ export LD_LIBRARY_PATH=/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/lib:/usr/local/nvidia/lib:/usr/local/nvidia/lib64:/var/drivers/nvidia/418.56/lib:/var/drivers/nvidia/418.56/lib64:/usr/local/cuda/lib64
+ LD_LIBRARY_PATH=/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/lib:/usr/local/nvidia/lib:/usr/local/nvidia/lib64:/var/drivers/nvidia/418.56/lib:/var/drivers/nvidia/418.56/lib64:/usr/local/cuda/lib64
+ export PATH=/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/bin:/usr/local/nvidia/bin:/usr/local/cuda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/drivers/nvidia/418.56/bin
+ PATH=/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/bin:/usr/local/nvidia/bin:/usr/local/cuda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/drivers/nvidia/418.56/bin
+ export C_INCLUDE_PATH=/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/include:/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/include/infiniband
+ C_INCLUDE_PATH=/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/include:/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/include/infiniband
+ export CPLUS_INCLUDE_PATH=/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/include:/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/include/infiniband
+ CPLUS_INCLUDE_PATH=/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/include:/var/drivers/mellanox/MLNX_OFED_LINUX-4.2-<IP_ADDRESS>-ubuntu16.04-x86_64/usermode/include/infiniband
+ lspci
+ grep -qE '[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F].[0-9] (3D|VGA compatible) controller: NVIDIA Corporation.*'
+ '[' -f /usr/local/nvidia/bin/nvidia-smi ']'
+ /bin/bash -x install-nvidia-drivers
++ uname -r
+ KERNEL_FULL_VERSION=4.15.0-72-generic
+ CURRENT_DRIVER=/var/drivers/nvidia/current
+ echo ======== If NVIDIA present exit early =========
======== If NVIDIA present exit early =========
+ nvidiaPresent
+ [[ -f /proc/driver/nvidia/version ]]
+ grep -q 418.56 /proc/driver/nvidia/version
+ lsmod
+ grep -qE '^nvidia'
+ lsmod
+ grep -qE '^nvidia_uvm'
+ [[ -e /dev/nvidia0 ]]
+ [[ -e /var/drivers/nvidia/418.56/lib64/libnvidia-ml.so ]]
+ [[ -e /etc/ld.so.conf.d/nvidia-drivers.conf ]]
+ return 0
+ '[' 0 == 0 ']'
+ [[ ! -L /var/drivers/nvidia/current ]]
+ exit 0
+ echo NVIDIA gpu detected, drivers installed
+ /bin/bash enable-nvidia-persistenced-mode.sh
NVIDIA gpu detected, drivers installed
=== Enable nvidia persistenced mode
nvidia-persistenced failed to initialize. Check syslog for more details.
+ exit 1

Brief what process you are following:
Please fill this for deployment related issues:

Operating type: Initial deployment

OpenPAI Environment:

OpenPAI version: v0.14.0
OS (e.g. from /etc/os-release): ubuntu 16.04
Hardware (e.g. core number, memory size, storage size, GPU type etc.): 8 gpu 2080 Ti
Others:

1: Run this script at your failed vm manually.
2: Reboot the vm.
After finishing the 2 steps above, please try to start drivers again.

Hi, @ydye
vm you mentioned is in docker dev-box, or in the server terminal?

It's the machine where you failed to install nvidia drivers.

I have deploy OpenPAI successfully, but when I modified some config and restart OpenPAI after the machine reboot this EROOR occurs.

Have you once install nvidia drivers with apt-get on your machine?

Yes, the pre-installed-nvidia-path: /usr/lib/nvidia-418 is the driver path.
I have couple of questions:

For first time using OpenPAI, do you recommend we use the default driver config or set the pre-installed-nvidia-path by ourself?
What does set-nvidia-runtime infer to?
If I want to use nvidia driver version 418.56, how do I sepecify the driver config as you recommend?

I followed your suggestion and use this script, but get the same ERROR.

1: I think use the pre-installed-nvidia-path will be better.
2: It's prepared for k8s device plugin. @abuccts @yqwang-ms
3: You can use pre-installed-nvidia-path

I looked at the var/log/syslog:
 dockerd[1609]: time="2020-01-07T13:55:03.370002883+08:00" level=warning msg="7edf4e312d34a502eeaa9e9d02bd74b8450f2e893e2d8ac666ac14a7015e9222 cleanup: failed to unmount IPC: umount /var/lib/docker/containers/7edf4e312d34a502eeaa9e9d02bd74b8450f2e893e2d8ac666ac14a7015e9222/mounts/shm, flags: 0x2: no such file or directory"


gtk{2,3}-x11 fails to build on Darwin

Issue description
gtk{2,3}-x11 fails to build on Darwin with the following message:
checking for CAIRO_BACKEND... no
configure: error: Package requirements (cairo-xlib >= 1.6) were not met:

No package 'cairo-xlib' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables CAIRO_BACKEND_CFLAGS
and CAIRO_BACKEND_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
builder for '/nix/store/dnay7nf0f9g6kli435ibgx8ic5yym67l-gtk+-2.24.32.drv' failed with exit code 1
error: build of '/nix/store/dnay7nf0f9g6kli435ibgx8ic5yym67l-gtk+-2.24.32.drv' failed

Last successful evaluation on Hydra was on April 20.
Steps to reproduce
% nix-build -I. -A gtk2-x11

Technical details

system: "x86_64-darwin"
host os: Darwin 18.6.0, macOS 10.14.5
multi-user?: no
sandbox: yes
version: nix-env (Nix) 2.2.2
channels(smaret): "nixpkgs-19.03pre170546.0f43790d2ce"
nixpkgs: /nix/store/381kbvy7byjv28l0knxb3s4g9mdmjwi7-master.tar.gz

Probably caused by b7a41a280f6172c13e9dc3f5d6fe499c9f898c0c

FYI, I'm still having issues with this, but it may be due to the merged changes from yesterday not yet being available in unstable.
My problem arose from use vim_configurable because it depends on gtk{2,3}. However, it is possible to work around this by eliminating the gtk dependency by overriding the guiSupport parameter. This was useful for me because I use vim from a terminal. See snippet below:
# with gtk{2,3} (old way):
pkgs.vim_configurable.customize { ... }

# without gtk{2,3} (workaround):
(pkgs.vim_confirgurable.override { guiSupport = "false"; }).customize { ... }

@dhruvio I’ve made another fix in gtk{2,3}-x11 (#61942). Maybe it solves your problem with vim-configurable? If not then I would suggest that you open a new issue that describes it.

Looks like it's still not working on macOS without the workaround. I think the problem has to do with the way the vim_configurable package was defined. I'll create another ticket. Thanks @smaret