STSCI proposal to add more support for ASDF serialization of astropy objects

It's in the proposal!

Is this a repeat of the following?

https://github.com/astropy/astropy-project/pull/348

Yes. It was suggested we re-propose for the regular funding requests rather than the "urgent" funding effort.

That's fine. I just want to make sure since it looks familiar. Thanks!

Correct.

Please react to this comment to vote on this proposal (👍, 👎, or no reaction for +0)

I'm writing on behalf of Astropy's Finance Committee. We are pleased to be able to let you know that, following consultation with the community, we are able to approve this request. We can currently fund the one year of work in the amount of $19,200 (US). We assume you will be using this full budget; if that is not the case, please contact us immediately.
Ana Gabela and I will be the contacts on the Finance Committee for this award. Please get in touch with us if you have any questions or concerns. Please do not reach out to NumFOCUS directly.
In addition, new to this funding cycle, is the assignment of a COTR (Contracting Officer's Technical Representative) to each funded project. This concept is borrowed from government funding agencies, although it is to be stressed that Astropy's goal is to make the COTR role as low-overhead as possible. The COTR’s primary responsibility is to make sure the work is happening at the expected pace and, if necessary, to be a liaison between the funded project and the Finance Committee or CoCo. The COTR for this project will be assigned shortly and we’ll also be sending out more details about how we see this working.
The next steps are:

Please make sure that the contractor (Elizabeth Madison) is registered with Open Collective: this is the system they will use to submit their invoices for payment. Note that their invoices should be submitted through the Astropy NASA project.
We will reach out through NumFOCUS, Astropy's Fiscal Sponsor, to set up an “independent contractor agreement” (ICA; effectively a contract) and formal scope of work for the project.
While this is in progress, the Finance Committee and the Coordination Committee will identify a COTR for each project. More information on this will be in the issue for the project once the COTR is identified.

We expect the work to be carried out between 2024-05-01 and 2025-04-30 (the “period of performance”). If you come to realize that the work will take more time than originally planned, you can apply for an extension following the procedure described at https://github.com/astropy/astropy-project/blob/main/finance/process/request-extension.md.
Congratulations — we are really looking forward to seeing you put these funds to good use!


Composite Indexes needed in the Production Environment for /progresses

Issue Description
Since a new query parameter, date, has been introduced in the /progresses route, we must create new composite indexes in the production environments. Please note that some indexes may already exist, but to ensure none are overlooked, I have included them below (the indexes after sl no. 4 might be already existing in our indexes):

Sl No
Collection ID
Fields indexed

1
progresses
taskId Ascending type Ascending date Descending name Descending

2
progresses
type Ascending date Ascending name Ascending

3
progresses
taskId Ascending type Ascending date Ascending name Ascending

4
progresses
userId Ascending date Ascending name Ascending

5
progresses
type Ascending date Descending name Descending

6
progresses
type Ascending userId Ascending date Ascending name Ascending

7
progresses
type Ascending userId Ascending date Descending name Descending

8
progresses
taskId Ascending date Ascending name Ascending

All indexes created on prod. Please let me know if there's anything missing.
Thank you for adding the info. Next time, would appreciate the links to generate index.


Pause Nix Derivation Cache?

I'm not totally sure what is going here, but I know this needs to be commented out for now.
I suppose I can look into it next week.  In the meantime, we need to pause this portion of the workflow.

Temporarily disabled by #466
"Enabling" issue tracked in #464


DISCUSSION: Refactor to use ETCH

One of the main reasons this package takes to long to go out on major releases is that one of the things I didn't want to use was jquery (and in this case, atom-space-pen wtv).
As stated

Etch is a library for writing HTML-based user interface components that provides the convenience of a virtual DOM, while at the same time striving to be minimal, interoperable, and explicit. Etch can be used anywhere, but it was specifically designed with Atom packages and Electron applications in mind.
Overview
Etch components are ordinary JavaScript objects that conform to a minimal interface. Instead of inheriting from a superclass or building your component with a factory method, you access Etch's functionality by passing your component to Etch's library functions at specific points of your component's lifecycle. A typical component is structured as follows:

So what do you think making this huge refactor for the sake of the community?

I agree jQuery is an unnecessary library in atom, and in my opinion in general web by now. I absolutely approve your view there.
I really like the idea to make the system simpler without introducing too much non-js type domain specific languages. One thing I dislike on etch is that render function because this does the opposite of this.
Example
render() {

I am a parent

      <ChildComponent adjective='good'>

Grandchild 1

Grandchild 2

      <ChildComponent/>

}

<ChildComponent adjective='good'> may is expressive but it is also something people have to learn in order to understand the purpose.
In addition to that mixing HTML and JS breaks default tooling, I mean why adding JSX to JS if JS could do the same thing. I am aware that etch is a package made and maintained by atom, but this really gives me the shivers, same as they include jQuery in atom-space-pen-views. I have this same view on react too.
So there are additional costs coming with this kind of approche, besides the refactor. And it may end up doing the opposite of simplifying the project.
Summarized: I like the idea, but I can foresee some additional cons that may be higher than the gain from using it. Maybe we can archive the same goal with native JS or something that does not bring in such costs.

I would strongly suggest you to take a closer look at vue.js.
It's a joy to work with, because you can very quickly implement user-interfaces.

The question here is that Etcher is "native" to Atom. Like space-atom was before. But it's all on the table

If you are considering to refactor, to cut down the (coding)time to interact with the DOM, you may want to go all the way. Etch appears still a little bit raw (as in close to raw DOM manipulation).

Well I'm coding a lot in vue and I can approve on @bfis statement. But for our needs even vue delivers a lot of overhead, we only need the Virtual DOM and the data bindings which are pretty simple to implement and none of the templating features, extended lifecycle or server-side rendering.

closing, this will be discussed for new major version


Inline sophia documentation for reexported modules

Current https://docs.rs/sophia/latest/sophia/ does not reexport documentation for workspace crates making documentation navigation a bit cumbersome. This PR calls #[doc(inline)] to re-export documentation:
https://github.com/pchampin/sophia_rs/blob/a5cca57cfad8aab51a31b24468068389b1d6616b/sophia/src/lib.rs#L27-L45

Any reason for not including sophia_turtle, sophia_jsonld and sophia_xml?

Any reason for not including sophia_turtle, sophia_jsonld and sophia_xml?

None other than to trigger a conversation about whether everything should be included. I'll make the changes.

None other than to trigger a conversation about whether everything should be included. I'll make the changes.

IIUC, the main benefit of inlining the documentation is to allow to search all re-exported crates in one place. I think users would be surprised if only a subset of these crates was showing in the search results...


Abnormal letter spacing in Chrome / Chromium

When calling:
html2canvas(document.getElementsByClassName('console'), {
      onrendered: function(canvas) {
        var img = canvas.toDataURL()
        var iframe = ''
        var x = window.open();
        x.document.open();
        x.document.write(iframe);
        x.document.close();
      },
      letterRendering: true,
    });

Both with or without letterRendering, this is what Chrome outputs:

When the output in Firefox is:

Any specific reason why it renders it like that?

The letter spacing (word spacing in this case) looks correct actually, what doesn't appear to be correct is the font family. Which version of html2canvas are you using? Can you replicate the issue on jsfiddle?

Thanks for your reply,
I'm using the version 0.5.0-beta4.
What do you mean the work spacing looks correct? Are you referring to the first picture I have shared? Would the font create such spacing between words?
Note that I'm using CodeMirror for the text editor that is rendered, specifically an Angular wrapper: ng2-codemirror.
I tried reproducing the issue to no avail here.

I also found the same problem in firefox and chrome. If you have a letter-spacing css rule on the text it will render the text with large gaps between each word. This was not the case in version 0.4.1 it used to render text perfectly but it was missing pseudo elements(:before :after)

Once you remove the letter-spacing rule everything goes back to normal for you? I'm not using it, neither in my component's css nor in my custom code-mirror's css file.

Yes After removing the letter-spacing rule from the CSS the issue is gone. there are no large spaces between words. it's something in the rendering of the page at the part of the letter-spacing that is messing it up.

Update! I just built the library from the latest sources on master and it works perfectly. everything looks really good so far. Previously I tried with the v0.5.0-beta4 release.

I don't use any letter-spacing property in my CSS and the issue is still present. I am using v0.5.0-beta4 though.

Try building from the latest master sources.

Done, and yet this does not solve the problem, the display remains the same.

Should be fixed with https://github.com/niklasvh/html2canvas/commit/77d258f1d8eeccf7e38235463a293b512c1ca3d0

Seems like the problem persists like such:

Here's how I rendered the element:
html2canvas(document.body).then(function(canvas) {
      document.body.appendChild(canvas);
});

I have downloaded the latest pre-release version as mentioned by you and replaced the old one.

@christopherkade does it fix it if you set the option letterRendering: true?

Sadly it does not, here's how I do it:
let element = document.getElementById('console');
const options = {
  letterRendering: true
};

html2canvas(element, options).then(function(canvas) {
  document.body.appendChild(canvas);

  var url = canvas.toDataURL();
  var img = ''
  var x = window.open();
  x.document.open();
  x.document.write(img);
  x.document.close();
});

Same result if I try the example given in the repository.

I have found a workaround for the matter (and it's not very clean):
// Package used to detect the browser used by the user
const browser = detect();
const element = document.getElementById('console');

// Set up my options
let options = {};
// For some reason foreignObjectRendering solves the spacing issue on Chrome but gives an error on Firefox, so I detect the browser and apply the adequate options.
if (browser && browser.name === 'chrome') {
  options = {
    useCORS: true,
    foreignObjectRendering: true
  };
}

// Open the canvas in a new window
html2canvas(element, options).then(function(canvas) {
  const url = canvas.toDataURL();
  const img = ''
  const x = window.open();
  x.document.open();
  x.document.write(img);
  x.document.close();
});

Note that the error I get on Firefox when using the second option is as follows:

Uncaught (in promise): [Exception... "Method not implemented"  ...

Solved here by removing CSS attribute font-variant-numeric: proportional-nums from HTML body.

same problem with Arabic language any suggestion please ?

@mohafouad  +1

@2xSamurai no :(

I have fixed this also by going to the div I want to screenshot and then I set the " font-variant: normal; " this has worked for me hope it helps .

fixed if I add font-variant: normal !important  to outer div of whole content (in antd project)

same problem, drived me crazy

font-variant: normal !important  not working

@Malarkey-Jhu's answer solved my problem.
The problem I had: Font family wasn't working and spacing was very wonky. Sometimes I would have overlapping letters.
What I do: During export I call element.style.setProperty('font-variant', 'normal') on the element with the text, and this allows the font-family to show properly, and the spacing to not be all wonky. Then I remove that property after I've finished exporting.

Based on the above solutions, this issue is fixed for me by changing -webkit-font-variant-ligatures and font-variant-ligatures to normal in codemirror css file. I am using CodeMirror version 5.42.2.

For me, this problem was caused by trying to take screenshots of text that was using a custom font (even if the fonts were loaded from the same domain). I had to change the font back to something built-in in the interim clone h2c creates, then everything worked perfectly (minus the custom fonts...):
html2canvas(element, {
      // removeContainer: false, //useful for testing changes to the interim iframe copy
      onclone: (document: Document) => {
        Array.from(
          document
            .querySelector(".analysis-container .ng-star-inserted")
            .children[0].querySelectorAll("*"),
        ).forEach((e) => {
          let existingStyle = e.getAttribute("style") || "";
          e.setAttribute("style", existingStyle + "; font-family: Helvetica, sans-serif !important");
        });
      },
    }).then(function (canvas) { //...etc


New tool Idea, Bot Control

As an Idea
What if a new tool was made, one that incorporated some of the kahoot-play and kahoot-rand
It would be very need to have a guided-rand, the tool would work something like this:
A user connects with 100 bots,
20 of those bots, when prompted with a question do not answer randomly as with the other 80 bots, witch will pick random answers like already in kahoot-rand
the 20 bots will wait for an amount of time before answering randomly,
the difference here from the regular kahoot-rand is that should a user input a number between 0-4 the 20 bots, should they have not timed out, will select that answer.
Should a user happen to know the answer the user can guide the bots to it, however if a user does not know the answer, the bots will answer randomly before the question ends,
Varibles would be:
Number of bots
Number of seconds before timeout
Percentage/Number of guided bots
Bot name list/Bot name
User input is 0-4 or no imput.
Sorry if i dident phrase my suggestion very well, your kahoot tool is very useful and well made already.

So you control 100 bots and if you don't know the answer they pick randomly?

Well yes in this example with 100 bots if you were to imput no answer they would pick randomly after a preset amount of delay, say, 3 seconds.


BAPP-645: User is prompted to sign in with farcaster when interacting with open frames

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/1

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
0

Sum
1


pep8: Ignore line break before binary operator

PEP8 has switched its guidance [1] for where a line break should occur
in relation to a binary operator, so don't raise this warning for
new code.
[1] https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator

In Python code, it is permissible to break before or after a binary operator, as long as the convention is consistent locally. For new code Knuth's style is suggested.

Our existing code base uses the old convention. We should continue to enforce it. Or alternatively, we should update all of the existing code to be in line with the updated guidance, and then enforce the new convention. However, we should not allow both.

Good point. Added a todo to look at updating our linters / code base style https://github.com/ARM-software/workload-automation/issues/1132


Wrap dialog boxes called from activity, But should be manual

I have an activity and wrapped the context with the way directed in documents of whit great project. in this activity I call another dialogFragment that has another specific font but same font of parent activity is set to dialog. Please help me to fix this.

You'd need to pass the wrapped context to the LayoutInflater as the activity context gets wrapped. Otherwise the LayoutInflater is passed the wrong context.
You're going to need to provide a clearer explanation and code if you want any help as the above question makes no sense.


Imported to Android Studio. Converted file format to UTF-8. Manifest …

…is updated; removed the sdk builds, as it is now handled in the gradle file

Hi @afathman. Good work bringing the project up-to-date. It's probably easier for people to start working with the code directly in Android Studios. However, our blog post uses tools that are not in your branch, so it's difficult to merge it onto our master. I'm going to edit our READ.MD to point your branch for those looking for an Android Studios port. Every few months we return to this project, we'll merge everything on our next visit. Thanks, Peter.

https://github.com/foxdog-studios/peepers/commit/d3147a807d77a904708ace259433c8427fe191f7


Make sure the new job is running when overwriting it with force flag

Did racetrack deploy --force on the running job, but the newer job failed to load.

However instead of seeing error message, it went successful and mistakenly it started presenting an older job as the new one.
Job had green status RUNNING.
Racetrack should make sure it's the newer version actually running when probing it. It's supposed to verify deployment timestamp, but maybe it doesn't really work.

Closing as there's no sign of it after merging https://github.com/TheRacetrack/racetrack/pull/377 fix into master, which improved checking actual version of a job.


⚠ ClamAV has degraded performance

In 6af2f54, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 82 ms

Resolved: ClamAV performance has improved in 871005e after 537 days, 15 hours, 27 minutes.


Hot reload not reporting script being updated

Reproduction steps:

Download iolite-v0.1.21
Download sample projects
Copy over sample projects and add to app_metadata.json data_sources
Run the editor and open, for example, 'sample_physics' world
Open script 'iolite-v0.1.21\sample_physics\media\scripts\gameplay_physics.lua
Open console F2
Change script
Nothing show up in console
Run game and the changes have no effect
Run game second time and the changes have effect

OS: Windows 11 x64

Yes, my active_data_source was not set right. Sorry. Feel free to close this.

Improved behavior in v0.2.22.


CComplexSplitter

Given a complex array, this processor separate it to real and imaginary parts. If property "CreateReal" is true, then the real part will be feed to out port "Real"; if property "Imaginary" is true, then the imaginary part will be feed to out port "Imaginary".

ok, I will do this part!

Done this Issue and send Pull request already.


Incorrect camera orientation after phone orientation change.

How can the issue of incorrect camera orientation be resolved when the phone is rotated from a vertical to a horizontal position?
Currently the camera image is rotated by 90 degrees in such a case.
I've checked deprecated project https://pub.dev/packages/qr_code_scanner and there this problem doesn't exist.

It's (unfortunately) a known limitation/issue:
https://github.com/juliansteenbakker/mobile_scanner/discussions/17

Thanks for pointing out the duplicate. So I'll follow #17


Update playbook for amending a change note.

Restructure for clarity.
Remove extraneous verbiage.
Avoid unnecessary use of the passive voice.
Use ordered lists for procedures where the order matters.
Make code snippets easier to copy/paste.
Specify language hints on code snippets for syntax highlighting.

Preview

One minor suggestion about the overnight environment sync jobs - all looks good though, happy to approve

Thanks! GitHub isn't showing me any suggestion though 🧐


[Feature] Add a hero section

Design the section according to the Figma design, if any

Can you provide me  the figma link for this section

@7Priyanshu9 You can start working from scratch. Figma is WIP as of now.

@jayzsh i am willing to make this section. so please assign this task to me

Hi Jayzsh, If the issue is currently available then I would like to work on this.

@mohitsaini07 Sure.


Error when attempting to create Sqlite3 db

I'm trying to use knex with ReactJs but am currently running into some problems just trying to create a table.
Code snippet:
    var knex = require('knex')({
            client: 'sqlite3',
            connection: { filename : "./testdb"},
            useNullAsDefault: true,
    //      debug:true
    });

knex.schema.createTable('users', function(table) {
        console.log("creating");
        table.increments('id').primary();
        table.string('username');
        table.string('password');
        table.timestamps();
})
.then(() => {})
.catch((error) => { console.log(error);});

var bookshelf = require('bookshelf')(knex);
export { knex, bookshelf }; `

Error output from the Chrome Console Tab:
TypeError: _this.driver.Database is not a constructor
    at http://localhost:3000/static/js/bundle.js:106754:17
    at Client_SQLite3.acquireRawConnection (http://localhost:3000/static/js/bundle.js:106753:13)
    at Object.create (http://localhost:3000/static/js/bundle.js:63023:17)
    at Pool._createResource (http://localhost:3000/static/js/bundle.js:81118:18)
    at Pool.dispense [as _dispense] (http://localhost:3000/static/js/bundle.js:81078:11)
    at Pool.acquire (http://localhost:3000/static/js/bundle.js:81200:9)
    at http://localhost:3000/static/js/bundle.js:63073:20
From previous event:
    at Client_SQLite3.acquireConnection (http://localhost:3000/static/js/bundle.js:63064:13)
    at http://localhost:3000/static/js/bundle.js:69280:31
    at http://localhost:3000/static/js/bundle.js:69278:36
    at Runner.ensureConnection (http://localhost:3000/static/js/bundle.js:69277:35)
    at Runner.run (http://localhost:3000/static/js/bundle.js:69127:43)
    at SchemaBuilder.Target.then (http://localhost:3000/static/js/bundle.js:62470:44)
    at Object.<anonymous> (http://localhost:3000/static/js/bundle.js:51485:5)
    at __webpack_require__ (http://localhost:3000/static/js/bundle.js:556:30)
    at fn (http://localhost:3000/static/js/bundle.js:87:20)
    at Object.<anonymous> (http://localhost:3000/static/js/bundle.js:51377:24)
    at __webpack_require__ (http://localhost:3000/static/js/bundle.js:556:30)
    at fn (http://localhost:3000/static/js/bundle.js:87:20)
    at Object.<anonymous> (http://localhost:3000/static/js/bundle.js:32596:2)
From previous event:
    at http://localhost:3000/static/js/bundle.js:69278:36
From previous event:
    at Runner.ensureConnection (http://localhost:3000/static/js/bundle.js:69277:35)
    at Runner.run (http://localhost:3000/static/js/bundle.js:69127:43)
    at SchemaBuilder.Target.then (http://localhost:3000/static/js/bundle.js:62470:44)
    at Object.<anonymous> (http://localhost:3000/static/js/bundle.js:51485:5)
    at __webpack_require__ (http://localhost:3000/static/js/bundle.js:556:30)
    at fn (http://localhost:3000/static/js/bundle.js:87:20)
    at Object.<anonymous> (http://localhost:3000/static/js/bundle.js:51377:24)
    at __webpack_require__ (http://localhost:3000/static/js/bundle.js:556:30)
    at fn (http://localhost:3000/static/js/bundle.js:87:20)
    at Object.<anonymous> (http://localhost:3000/static/js/bundle.js:32596:2)
    at __webpack_require__ (http://localhost:3000/static/js/bundle.js:556:30)
    at fn (http://localhost:3000/static/js/bundle.js:87:20)
    at Object.<anonymous> (http://localhost:3000/static/js/bundle.js:10825:13)
    at __webpack_require__ (http://localhost:3000/static/js/bundle.js:556:30)
    at fn (http://localhost:3000/static/js/bundle.js:87:20)
    at Object.<anonymous> (http://localhost:3000/static/js/bundle.js:591:19)
    at __webpack_require__ (http://localhost:3000/static/js/bundle.js:556:30)
    at http://localhost:3000/static/js/bundle.js:579:37
    at http://localhost:3000/static/js/bundle.js:582:10

It doesn't seem like anything is missing, could it be an environmental issue?

@oscarhou
It's obvious that the browser cannot use a SQL database

@absolux
Thanks, I guess I had the wrong idea about SQLite3, I was using SQLite3 for initial prototyping purposes to avoid having to write an API to interface it.


BIGSERIAL column type does not result in column having auto-generated value from sequence. Sequence is also not created.

Environment
java version "1.8.0_241"
Java(TM) SE Runtime Environment (build 1.8.0_241-b07)
Java HotSpot(TM) 64-Bit Server VM (build 25.241-b07, mixed mode)
Liquibase Version:
This issue is present in liquibase-core:3.10.3 . Previous released version: 3.10.1 works correctly (see description)
Database Vendor & Version: Postesql:9.6.15
Operating System Type & Version:
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.3 LTS
Release:	20.04
Codename:	focal
Description
Using liquibase-core:3.10.3 the following column definition does not create sequence and set correct column default value:

The resulting SQL Create script will be:
CREATE TABLE IF NOT EXISTS harvester.resource_entry_event
(
    id uuid NOT NULL,
    sequence_identifier bigint NOT NULL
)
Going back to prior version: 3.10.1 the above column definition will be created correctly. The SQL to create the table will be:
CREATE TABLE IF NOT EXISTS harvester.resource_entry_event
(
    id uuid NOT NULL,
    sequence_identifier bigint NOT NULL DEFAULT nextval('harvester.resource_entry_event_sequence_identifier_seq'::regclass)
)
...and sequence will be created.
It looks like this fix from 3.10.3 has no effect: https://github.com/liquibase/liquibase/pull/1010

Hi @swav Thanks for creating this issue.  Can you share the changeset that you are using that shows the issue?

@molivasdat , I've attached the entire table definition changelog. I've used liquibase 3.10.3 and postgesql 9.6.15 . Thanks for looking into this :)

We dont expect to create a sequence, so this behavior its correct.


feat: worker format with query params

Description
fix: #8466

Additional context

support import worker from worker.js?worker&format=esm
support import worker from worker.js?worker&format=iife
worker query dts

What is the purpose of this pull request?

[ ] Bug fix
[x] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the Commit Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[x] Ideally, include relevant tests that fail without this PR but pass with it.

@patak-dev is need to output two format chunks? In fact, two workers can be exported, and users can choose what they like. The remaining workers will generate files but have no code at runtime(clean it by tree-sharking)

emm... I think the url options we can replace with export const url = "${url}" 😁

And use this plan to judge whether the worker needs to be an inline worker https://github.com/vitejs/vite/issues/7352#issuecomment-1070552776

now I think we can remove all current url query, and then make the content of the url query export by default.

about url we can export direct. Because it has no extra performance overhead.
about inline worker we can export it by base64 if it filesize less than worker chunk limit and format by iife. or not we can export it default.
Because it may have a little extra performance overhead. (sourcemap and base64 strings)
about differe worker format differe feature, I prefer to specify to the user. It may be that I don't fully understand what your suggest.

Oh, I see, that is an interesting idea. Maybe something to explore in v4 once we also remove the query in favor of as 'worker'? Something that I like about it is that as only lets you specify one string and not more options, so it may be a way for us to avoid that.
This should also be used not only for workers, and I don't know if it is always possible though. For example in CSS, the ?inline will avoid the side effect of adding the styles so you can't do the same trick there, but maybe that is a special case. It also feels a bit strange that we would potentially allow users to import the worker, the url, and the inline string all at once.

I think index.css will like this.
export const inline = 'css code'
export default 'css url'

in v2  we import the internal module like
import indexCSSURL from "./index.css"
import indexCSSRaw from "./index.css?inline"

import worker from "./worker?worker"
import workerURL from "./worker?worker&url"
import inlineWorker from "./worker?worker&inline"

in v3
import indexCSSURL ,{ inline as indexCSSRaw } from "./index.css"
import { url as workerURL, inline }, worker from "./worker?worker"

oh, I see. ?inline makes it a virtual module. I think this method can reduce the request parameters of the virtual module

But now it seems that url, raw, inline are virtual modules based on vite, and they remain as they are, which is easier for users to accept. ?format is an unique to workers that can be confusing.
IIUC, your suggestion is according to the worker type we collected to interpret the format mode.
type: module -> format: esm. type: classic -> format: iife.


Add mappings for Post.provider_display_name

Current coverage is 88.12% (diff: 100%)

Merging #44 into master will increase coverage by 0.14%

@@             master        #44   diff @@
==========================================
  Files            13         13
  Lines           699        699
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            615        616     +1
+ Misses           84         83     -1
  Partials          0          0

Powered by Codecov. Last update 0172690...f979b8e


Add global.json to enable importing to VS 16.5.3.

Without global.json, this throws an error in VS 16.5.3 :
"The project file cannot be opened by the project system, because it is missing some critical imports or the referenced SDK cannot be found.
Detailed Information:
Unable to locate the .NET Core SDK. Check that it is installed and that the version specified in global.json (if any) matches the installed version."

Thanks for the contribution!
The real problem is that the common global.json at the root of the repo uses SDK version 3.1.103, which corresponds to VS2017.  That needs to be changed to 3.1.201 instead.
3.1.103 and 3.1.201 are equivalent but differ in their support for VS2017 and VS2019 respectively. We should indeed change this repo to use VS2019 based SDK versions.
The value of altsdk.netcoreapp3.1 should also be updated in the main global.json.

Just so I'm clear, I'd recommend fixing this in the repo-wide global.json instead of introducing a new one as you have done. 😄

Closing as stale and this is not the right fix.


Memory usage goes through the roof when using Prometheus histograms (summaries)

Hi! We're using
metrics = "0.20.1"
metrics-exporter-prometheus = "0.11.0"

in our program, with an HTTP server exposing a Prometheus scrape point.
We noticed a gigantic memory usage related to histograms.
I still haven't figured all things out, but I'm letting you know in case you were able to help and weigh in on some matters.
So far two distinct issues have been identified:
1. unbounded memory growth in histograms when PrometheusHandle::render is not called.
IIUC some raw histogram data gets "compacted" in:
https://github.com/metrics-rs/metrics/blob/64d5c5ae63babafbf3875f723ed263efe9332647/metrics-exporter-prometheus/src/recorder.rs#L93
There is no interface to trigger that other than render, which is suboptimal, because:

there is no clear indication that it must be done (admittedly, I might have missed that in the docs, so please bear with me; that said, it is surprising)
render does a bunch of things that are not really needed to compact the raw data
typically render will be called when metrics scraping happens. There is no way to ensure scrapping from an external component, so one has to periodically call render() oneself;

What about calling (or even better - scheduling background compaction) when there are too many recorded histogram samples (globally)? WDYT?
2. the actual memory allocations happening during record don't seem reasonable
In our not-so-small program according to heaptrack 75% of all allocations happen during Histogram::record:

Furthermore, these allocations seem to have >1kb size (!??)

This sounds a bit excessive :)
It looks as if every record was causing a creation of a new Block in AtomicBucket::push

re 2:
I think it may be just us using the histogram too frequently.

As far as the first problem: yes, this is an outstanding issue (noted originally in #245) that I'm willing to accept a PR for. The linked issue lays out some possible approaches I'd accept for solving the problem.
As far as the second problem: histogram collection is based on AtomicBucket, which is an unbounded queue modeled after crossbeam's unbounded MPMC queue, SegQueue. It indeeds allocates memory in large blocks, which are closer to 512B, but with the additional fields, etc... I'm guessing the allocator is rounding up to 1KB.
However, it does not allocate a block every time a sample is recorded. Blocks are allocated roughly every N samples, where N is the pointer width (in bits) of the platform, so 64 for x86-64, etc. If the current block is full, all contending writers will speculatively allocate a new block and try to install it, which can lead to additional allocations beyond the expected "once every N pushes" overhead.
AtomicBucket is fast, and generally it would be hard to truly use it "too frequently": it supports insertion rates in the millions/second, even with contention. However, depending on your constraints -- such as avoiding ongoing allocations at runtime -- it could certainly be unsuitable for a particular workload.
As the second problem is simply the nature of AtomicBucket, and the first problem is being tracked in #245, I'm going to close this issue.

Thanks a lot for your fast response! I'll follow up in #245
I'd like to comment on the "too frequently" part:
Our program processes ~1GB/s, and when not scraping the histograms (we have 2 frequently accessed ones) they consume ~160MB of heap per minute. That is not much in comparison but is very visible in our case because we aggressively reuse buffers to fit in a pretty tight memory budget we have.


Label and Dropdown Updates

Description
This PR adds some new features to Label and SelectDropdown to ease composition for common patterns:

Adds LabelSecondaryButton that encapsulates settings that need to be used consistently for the secondaryButton option in Labels.
Adds a LabelGroup component for display inline/wrapping lists of Labels.
Adds an option on SelectDropdown for showing selected items as Labels below the dropdown that can also be removed (React only)

Screenshots
New showSelectionsAsLabels option on React SelectDropdown:

No visual changes otherwise.
Bonus: Adds fullWidth prop to React Button to sync up with the one in Rails.
Test notes
See Elements > Label and Elements > Dropdown to verify no visual changes or errors.
See Storybook > Dropdown > Multiselect to see new component in use.
Steps for testing
These are new features that do not create issues with existing use of these components but do open up opportunities to simplify some existing implementations.
Verify existing uses are unaffected in the following:

Label: ensure labels look same and function as they have to date:

[ ] Product outline editor (React): publish status dropdowns
[ ] Contact import bulk actions step (React): Tag selections that appear below dropdown
[ ] Settings > Domain (Rails): see Kajabi default is displaying as before
[ ] Offers (Rails): publish status label appears as expected (FYI: clicking off of this dropdown does not appear to function as expected and dismiss the dropdown. This appears to be the functionality before this PR as well. A patch may be needed to how this component is implemented here.)

Dropdown:

[ ] Product outline editor (React): any existing dropdowns
[ ] Contact import bulk actions step (React): Tag selection dropdown
[ ] Offers (Rails): ... options menu
[ ] Product catalogue (Rails): any dropdowns

BONUS: Button: no changes should affect React-based buttons. Confirm that any buttons in the follow appear as expected:

[ ] New Contact import process
[ ] Product outline manager

@monkeypox8 I've fixed this. Sorry for the trouble!


Doesn't seem to work often?

I've followed all the instructions given to run this, and yet the program very rarely detects people. I've summoned about 20 different people now and it's only worked twice.

.

This is a known bug. Essentially Steam doesn't flush the log file after each line, so sometimes peers are not detected. In my own experience it works almost 100% of the time, so I'm not exactly sure what governs the rate at which the log file is flushed. This will be fixed in the next update, which will use internal hooks inside the Steam process to identity peers.

I see, thanks for clarifying.


Extending Number does not work with operators

If I create a new class that extends Number, operators cannot be applied to the new class.
However, it works as expected in JavaScript.
TypeScript Version:  3.9.5
Search Terms:

extend Number
extend base types
valueOf

Code
class Test extends Number { }

let a = new Test(5);
let b = new Test(10);

let c = a + b;

Expected behavior:
c should equal 5.
Actual behavior:
Compiler returns: Operator '+' cannot be applied to types 'Test' and 'Test'
Playground Link: Provided
This appears related to #2031, #2361

This is another manifestation of #2361


feat: show user as a link in feedback response table

Hey, I just made a Pull Request!

:heavy_check_mark: Checklist

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

Looks like the build is failing here @drodil! :pray:

Thanks! :pray:


bamtofastq writes redundant reads

If a read (or pair of reads) is mapped to multiple locations in your BAM file, then bedtools bamtofastq will write multiple copies of that read to your output FASTQ file.
If you have a FASTQ file generated by bamtofastq, you can check for duplicate reads with:
(Columns: Line number, Read ID, Cumulative number of duplicates)
cat file.end1.fq | perl -e 'while ($a=<>) {$b=<>;$c=<>;$d=<>; chomp $a; if ($H{$a}++) {print "$. $a $H{$a}\n"} }' | head

112 @H7TVLADXX140423:2:1101:1166:90617/1 2
116 @H7TVLADXX140423:2:1101:1166:90617/1 3
120 @H7TVLADXX140423:2:1101:1166:90617/1 4
124 @H7TVLADXX140423:2:1101:1166:90617/1 5
128 @H7TVLADXX140423:2:1101:1166:90617/1 6
220 @H7TVLADXX140423:2:1101:1173:67468/1 2
224 @H7TVLADXX140423:2:1101:1173:67468/1 3
228 @H7TVLADXX140423:2:1101:1173:67468/1 4
232 @H7TVLADXX140423:2:1101:1173:67468/1 5
348 @H7TVLADXX140423:2:1101:1182:83769/1 2

Notice that read @H7T...617 is repeated 6 times, and the last 5 copies are listed on lines 112, 116, 120, 124, and 128 in the file.
To avoid this problem, you can use Picard SamToFastq.jar.

Hi,
it's actually a bit worse, I get wrong output with multi-mapping paired-end reads if one of the alignment hits is in reverse direction. E.g.

_R1.fastq:                                           vs       _R2.fastq;
......
@HWI-ST865:341:H9FJ7ADXX:1:1101:1405:93045/1                 @HWI-ST865:341:H9FJ7ADXX:1:1101:1405:93045/2
AAAGACTCAGCGTCGGTAAAGACTCAGCGTCAGTAAAAGAGTCAGCGTCA           AAAGACTCAGCGTCGGTAAAGACTCAGCGTCAGTAAAAGAGTCAGCGTCA ### NOTE: identical sequence, will give mapping error
+                                                            +
CCCFFFFFHHHHHJJJGHIJJJJJJIJJIGIJJIJJJIJHJFGIIGIHJI           CCCFFFFFHHHHHJJJGHIJJJJJJIJJIGIJJIJJJIJHJFGIIGIHJI
@HWI-ST865:341:H9FJ7ADXX:1:1101:1405:93045/1                 @HWI-ST865:341:H9FJ7ADXX:1:1101:1405:93045/2
AAAGACTCAGCGTCGGTAAAGACTCAGCGTCAGTAAAAGAGTCAGCGTCA           TAATTAATGCATTCATACAGAGCGCATTTCCAGCATCATTTATTGGATAG
+                                                            +
CCCFFFFFHHHHHJJJGHIJJJJJJIJJIGIJJIJJJIJHJFGIIGIHJI           CCCFFFFFHHHHHJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJIIIJII
@HWI-ST865:341:H9FJ7ADXX:1:1101:1405:93045/1                 @HWI-ST865:341:H9FJ7ADXX:1:1101:1405:93045/2
TAATTAATGCATTCATACAGAGCGCATTTCCAGCATCATTTATTGGATAG           TAATTAATGCATTCATACAGAGCGCATTTCCAGCATCATTTATTGGATAG ### NOTE: identical sequence, will give mapping error
+                                                            +
CCCFFFFFHHHHHJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJIIIJII           CCCFFFFFHHHHHJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJIIIJII

(these lines have identical line numbers, so would be taken in pairs by a mapping program)
This behaviour is something to keep in mind while using (and, preferably, fixing :-) bamToFastq

Hi All,
I just ran into this issue and have submitted a pull request that fixes these issues. @arq5x I don't think the read name hash table is necessary as the BAM file is required to be name sorted anyways. Thus all mate reads are together and the file simply needs to be read in until another read name is encountered.
This pull request should solve both the spurious warnings problem as well as including a read many times in the output fastq.

now fixed in master thanks to PR from @marcus1487


Split into several packages

cabal doesn't allow passing flags to dependencies which means I can't configure tcp-streams to only build with tls library support. It will always build with HOpenSSL alongside which is very hard to get right on Windows.
A solution would be to split tcp-streams in 3 packages:

tcp-streams which is tcp-streams modulo tls and HOpenSSL
tcp-streams-tls which adds TLS support via tls library
tcp-streams-openssl which adds TLS support via HOpenSSL

There's a cabal.project file which you can use to assign flags, but it's only available to new-build system. But stack support flag quite well i think.
But this is indeed an embarrassing problem(I'm using MacOS which always have trouble with libcrypto path). On one hand, splitting does make sense since these module is independent mostly. On the other hand this will make mantainence and the mantainence of every package depending tcp-streams(such as mysql-haskell) became quite annoying. Now they either depending on all of these packages or making a split just like what you proposed.
I have to think it over before deciding what is the best thing to do, maybe you can give more comparison on flag vs split package?

The problem is the distribution through hackage. It doesn't use cabal.project or stack.yaml as you know that way when I want to release a new library I only have the knobs in my cabal file which doesn't allow passing flags to dependencies. I rather like libraries with clever defaults where I don't have to fiddle with some build-path issues and such.
A split in tcp-streams would also incur a split in mysql-haskell which is annoying. Actually it is the package I was concerned with as I started investigating a persistent-mysql-haskell and I wouldn't want to include HsOpenSSL per default there as it imposes a burden on newcomers.
I can't think of another way as the split. Maybe you can work out the interface in mysql-haskell a bit so you can plug in any TLS backend without imposing a too strong cohesion.

OK, since what we want to solve is the openssl dependency, here is my judgement:

Split tcp-streams into tcp-streams(raw and tls) and tcp-streams-openssl(use HsOpenSSL).
Split mysql-haskell into mysql-haskell and  mysql-haskell-openssl respectively.

You should be able to use TLS via tcp-streams, which use haskell tls package. And If you want some extra performance, tcp-streams-openssl is at your service as long as you can deal with the building.
Now every package depend on tcp-streams should follow this convention: one package with default TLS support and another one using tcp-streams-openssl.
As for your persistent-mysql-haskell, first thanks for taking time write this! is it acceptable to split a  persistent-mysql-haskell-openssl package? you can expose an internal module in persistent-mysql-haskell and use that as a basis, so persistent-mysql-haskell-openssl  is just a thin layer of openssl wrappers.

@winterland1989 Yes, I think this will work.
Ok, the plan is to create two packages:

persistent-mysql-haskell
persistent-mysql-haskell-openssl

This will work for me.

Done, I'll upload to hackage after some checking(cabal file ..,etc.), If you find any problem please report.


Unattended installation anbd updates?

It would be nice to have information on unattended setup and update for Azure Data Studio!

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

ID: 811ed1f4-1c78-aa1b-e752-307250ca8eb7
Version Independent ID: f36629bf-b2e6-4993-7c77-32fa311ea942
Content: Download and install - Azure Data Studio
Content Source: docs/azure-data-studio/download.md
Product: sql
GitHub Login: @stevestein
Microsoft Alias: sstein

@MightyPen That is absolutely not helpful of your engineering team!
You might tell them about things like SCCM, the cloud and containers or even automation which are pretty helpful things when working as an engineer ;-)
Nonetheless, here is the command line that works for an unattended installation:
& ".\azuredatastudio-windows-setup-1.3.9" /VERYSILENT /MERGETASKS=!runcode

@yualan Alan, Here in Issue 1597, the customer has replied with further thoughts and information that you and Steve might want to consider for the documentation article.  Please see his preceding Comment box.
Thanks.
CC: @stevestein

I am reOpening this Issue 1597.
Due to current resourcing situations, this Issue 1597 might have to wait longer than usual to be more fully addressed.

A new internal DevO work item = 1468858 is continuing to track this aging Issue 1597.
When the DevO is processed and Closed, this Issue 1597 will also be updated with the final information (including an @ notification to the original poster.
https://mseng.visualstudio.com/TechnicalContent/_workitems/edit/1468858
https://dev.azure.com/MsEng/TechnicalContent/_workitems/edit/1468858
CLOSING this Issue 1597 (at least for now).
@stevestein @yualan
. .


Consistent output behavior

I see some commands like sort were given the power to write back to same file.
However other commands like slice do not have this same power:
$ xsv slice -e 20 -o sunday.csv worldcitiespop.csv

$ wc sunday.csv
 21  25 970 sunday.csv

$ xsv slice -e 10 -o sunday.csv sunday.csv

$ wc sunday.csv
0 0 0 sunday.csv

Is this intentional or an oversight?

https://github.com/BurntSushi/xsv/issues/92


Hide internal fields from sheet template creation form

We should hide all fields starting with __ from the form. This will hide fields the user is not expected to modify (and which do nothing even if the user does).
An exception this is __output_dir (or TPL_DIR_FIELD), which is relevant for exports.

Done. Also manually added the non-standard _library_types field I found in one of the templates into HIDDEN_SHEET_TEMPLATE_FIELDS.


Split off sgx-heap into enarx-heap

Signed-off-by: Nathaniel McCallum<EMAIL_ADDRESS>

@haraldh Looks like the GHA runner is offline. I think this is due to us running the container using systemd and it being unable to find the dbus session socket.
WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available
WARN[0000] For using systemd, you may need to login using an user session
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 1009` (possibly as root)
WARN[0000] Falling back to --cgroup-manager=cgroupfs

@haraldh Looks like the GHA runner is offline. I think this is due to us running the container using systemd and it being unable to find the dbus session socket.
WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available
WARN[0000] For using systemd, you may need to login using an user session
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 1009` (possibly as root)
WARN[0000] Falling back to --cgroup-manager=cgroupfs

fixed


Message to go on modal

I think that message should go in a pop up and a user should be able to copy the OTP to send to their friend/family.
Along with the line already there, additionally it should say, "Please share this OTP with your contact."

@summikhan11 is there a UI for this change or it's fine just to come up with something on my own ?

i'll add a link


libsodium: mbedtls SHA512 breaks crypto_sign

In default configuration libsodium ESP-IDF component returns invalid data for crypto_sign module (e.g crypto_sign_detached). However, after removing *sha*.{h,c} files from ESP32 port and adding crypto_hash/sha{256,512}/cp back to Makefile, crypto_sign starts to work.
Apparently, custom libsodium SHA512 API is not implemented correctly (SHA512 works for "normal" uses).

For completness: this patch fixes the problem, but has undesirable effect of disabling SHA512 and SHA256 hardware acceleration.

Hi @zielmicha ,
Thanks very much for reporting this and sorry for the hassle. I'm able to reproduce it here and have a fix (including a new config option to disable the mbedTLS wrapping for easier testing).
Fix should be on github soon, until then the workaround you have seems like a good one.
Angus

Thanks for your patience with this issue.
A small additional note now this fix has landed, during testing I realised that the libsodium SHA API and ESP32 hardware accelerated SHA are incompatible.
The reason is that the mbedTLS SHA API has an mbedtls_shaxxx_free() function which needs to be called when the user is done with a SHA context. For hardware accelerated SHA sessions, we use this to free any in-progress SHA session which is loaded into the hardware unit but hasn't calculated the final digest value yet.
libsodium has no such function, the assumption is that once the SHA state structure is no longer being used the SHA session is done. As a result, if a SHA session is never finished (ie the in-progress digest is discarded without the final value being calculated), there's no way for IDF to know that the context can be removed from hardware and the hardware reused. Essentially once this happens the hardware instance is "leaked' and all remaining SHA sessions run in software.
There's no fix to this that doesn't involve either extending the libsodium API or reworking the ESP32 SHA acceleration hardware. So I've made the two features mutually exclusive in the IDF configuration.


px deploy error when depoying vizier

Describe the bug
px deploy  not finished
err: Deploying Vizier  ERR: Vizier.px.dev "pixie" is invalid
To Reproduce
Steps to reproduce the behavior:
./px version
Pixie CLI
Update to version "0.7.17" available. Run "px update cli" to update.
0.7.15+Distribution.adb23c5.20220630065906.1.jenkins
❯ px deploy --pem_memory_limit=5Gi
Pixie CLI
Update to version "0.7.17" available. Run "px update cli" to update.
Running Cluster Checks:
✔    Kernel version > 4.14.0
✔    Cluster type is supported
✔    K8s version > 1.16.0
✔    Kubectl > 1.10.0 is present
✔    User can create namespace
✕    Cluster type is in list of known supported types  ERR: Cluster type is not in list of known supported cluster types. Please see: https://docs.px.dev/installing-pixie/requirements/
Some cluster checks failed. Pixie may not work properly on your cluster. Continue with deploy? (y/n) [y] : y
Installing Vizier version: 0.11.9
Generating YAMLs for Pixie
Deploying Pixie to the following cluster: kubernetes-admin@kubernetes
Is the cluster correct? (y/n) [y] : y
Found 1 nodes
✔    Installing OLM CRDs
✔    Deploying OLM
✔    Deploying Pixie OLM Namespace
✔    Installing Vizier CRD
✔    Deploying OLM Catalog
✔    Deploying OLM Subscription
✔    Creating namespace
✕    Deploying Vizier  ER    DeployingR: Vizier.px.dev "pixie" is invalid: spec.dataCollectorParams: Invalid value: "null": spec.dataCollectorParams in body must be of type object: "null"
FATA[0168] Failed to deploy Vizier                       error="Vizier.px.dev "pixie" is invalid: spec.dataCollectorParams: Invalid value: "null": spec.dataCollectorParams in body must be of type object: "null""
Screenshots

Logs
Please attach the logs by running the following command:
./px collect-logs
[pixie_logs_20220822190622.zip](https://github.com/pixie-io/pixie/files/9393778/pixie_logs_20220822190622.zip)

App information (please complete the following information):

Pixie version:             0.7.17 AND 0.7.15
K8s cluster version:   v1.19.8
Node Kernel version: 5.4
Browser version:        104.0.5112.79

Hi @oslet ! Sorry to hear the deployment isn't working as expected.
Would you mind sharing the output of kubectl describe crd vizier and kubectl describe vizier pixie -n pl ? Make sure to blank out the deploy key in the spec for the latter command.

Hi @oslet ! Sorry to hear the deployment isn't working as expected. Would you mind sharing the output of kubectl describe crd vizier and kubectl describe vizier pixie -n pl ? Make sure to blank out the deploy key in the spec for the latter command.

kubectl describe crd vizier

kubectl describe crd vizier
Name:         viziers.px.dev
Namespace:
Labels:       operators.coreos.com/pixie-operator.px-operator=
Annotations:  controller-gen.kubebuilder.io/version: v0.4.1
API Version:  apiextensions.k8s.io/v1
Kind:         CustomResourceDefinition
Metadata:
  Creation Timestamp:  2022-08-17T10:01:22Z
  Generation:          1
  Managed Fields:
    API Version:  apiextensions.k8s.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .:
          f:controller-gen.kubebuilder.io/version:
      f:spec:
        f:conversion:
          .:
          f:strategy:
        f:group:
        f:names:
          f:kind:
          f:listKind:
          f:plural:
          f:singular:
        f:scope:
        f:versions:
      f:status:
        f:storedVersions:
    Manager:      px
    Operation:    Update
    Time:         2022-08-17T10:01:22Z
    API Version:  apiextensions.k8s.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:status:
        f:acceptedNames:
          f:kind:
          f:plural:
        f:conditions:
    Manager:      catalog
    Operation:    Update
    Time:         2022-08-17T10:02:25Z
    API Version:  apiextensions.k8s.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          .:
          f:operators.coreos.com/pixie-operator.px-operator:
    Manager:         olm
    Operation:       Update
    Time:            2022-08-22T09:01:11Z
  Resource Version:  1706615
  Self Link:         /apis/apiextensions.k8s.io/v1/customresourcedefinitions/viziers.px.dev
  UID:               acc9a796-3575-4c54-9ea8-3a863b8040df
Spec:
  Conversion:
    Strategy:  None
  Group:       px.dev
  Names:
    Kind:       Vizier
    List Kind:  VizierList
    Plural:     viziers
    Singular:   vizier
  Scope:        Namespaced
  Versions:
    Name:  v1alpha1
    Schema:
      openAPIV3Schema:
        Description:  Vizier is the Schema for the viziers API
        Properties:
          API Version:
            Description:  APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values.  Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
            Type:         string
          Metadata:
            Type:  object
          Spec:
            Description:  VizierSpec defines the desired state of Vizier
            Properties:
              Clock Converter:
                Description:  ClockConverter specifies which routine to use for converting timestamps to a synced reference time.
                Enum:
                  default
                  grpc
                Type:  string
              Cloud Addr:
                Description:  CloudAddr is the address of the cloud instance that the Vizier should be pointing to.
                Type:         string
              Cluster Name:
                Description:  ClusterName is a name for the Vizier instance, usually specifying which cluster the Vizier is deployed to. If not specified, a random name will be generated.
                Type:         string
              Custom Deploy Key Secret:
                Description:  CustomDeployKeySecret is the name of the secret where the deploy key is stored.
                Type:         string
              Data Access:
                Description:  DataAccess defines the level of data that may be accesssed when executing a script on the cluster. If none specified, assumes full data access.
                Enum:
                  Full
                  Restricted
                Type:  string
              Data Collector Params:
                Description:  DataCollectorParams specifies the set of params for configuring the dataCollector. If no params are specified, defaults are used.
                Properties:
                  Custom PEM Flags:
                    Additional Properties:
                      Type:       string
                    Description:  This contains custom flags that should be passed to the PEM via environment variables.
                    Type:         object
                  Datastream Buffer Size:
                    Description:  DatastreamBufferSize is the data buffer size per connection. Default size is 1 Mbyte. For high-throughput applications, try increasing this number if experiencing data loss.
                    Format:       int32
                    Type:         integer
                  Datastream Buffer Spike Size:
                    Description:  DatastreamBufferSpikeSize is the maximum temporary size of a data stream buffer before processing.
                    Format:       int32
                    Type:         integer
                Type:             object
              Deploy Key:
                Description:  DeployKey is the deploy key associated with the Vizier instance. This is used to link the Vizier to a specific user/org. This is required unless specifying a CustomDeployKeySecret.
                Type:         string
              Dev Cloud Namespace:
                Description:  DevCloudNamespace should be specified only for dev versions of Pixie cloud which have no ingress to help redirect traffic to the correct service. The DevCloudNamespace is the namespace that the dev Pixie cloud is running on, for example: "plc-dev".
                Type:         string
              Disable Auto Update:
                Description:  DisableAutoUpdate specifies whether auto update should be enabled for the Vizier instance.
                Type:         boolean
              Leadership Election Params:
                Description:  LeadershipElectionParams specifies configurable values for the K8s leaderships elections which Vizier uses manage pod leadership.
                Properties:
                  Election Period Ms:
                    Description:  ElectionPeriodMs defines how frequently Vizier attempts to run a K8s leader election, in milliseconds. The period also determines how long Vizier waits for a leader election response back from the K8s API. If the K8s API is slow to respond, consider increasing this number.
                    Format:       int64
                    Type:         integer
                Type:             object
              Patches:
                Additional Properties:
                  Type:       string
                Description:  Patches defines patches that should be applied to Vizier resources. The key of the patch should be the name of the resource that is patched. The value of the patch is the patch, encoded as a string which follow the "strategic merge patch" rules for K8s.
                Type:         object
              Pem Memory Limit:
                Description:  PemMemoryLimit is a memory limit applied specifically to PEM pods.
                Type:         string
              Pem Memory Request:
                Description:  PemMemoryRequest is a memory request applied specifically to PEM pods. It will automatically use the value of pemMemoryLimit if not specified.
                Type:         string
              Pod:
                Description:  Pod defines the policy for creating Vizier pods.
                Properties:
                  Annotations:
                    Additional Properties:
                      Type:       string
                    Description:  Annotations specifies the annotations to attach to pods the operator creates.
                    Type:         object
                  Labels:
                    Additional Properties:
                      Type:       string
                    Description:  Labels specifies the labels to attach to pods the operator creates.
                    Type:         object
                  Node Selector:
                    Additional Properties:
                      Type:       string
                    Description:  NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node's labels for the pod to be scheduled on that node. More info: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/ This field cannot be updated once the cluster is created.
                    Type:         object
                  Resources:
                    Description:  Resources is the resource requirements for a container. This field cannot be updated once the cluster is created.
                    Properties:
                      Limits:
                        Additional Properties:
                          Any Of:
                            Type:                              integer
                            Type:                              string
                          Pattern:                             ^(\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))(([KMGTPE]i)|[numkMGTPE]|([eE](\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))))?$
                          X - Kubernetes - Int - Or - String:  true
                        Description:                           Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
                        Type:                                  object
                      Requests:
                        Additional Properties:
                          Any Of:
                            Type:                              integer
                            Type:                              string
                          Pattern:                             ^(\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))(([KMGTPE]i)|[numkMGTPE]|([eE](\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))))?$
                          X - Kubernetes - Int - Or - String:  true
                        Description:                           Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
                        Type:                                  object
                    Type:                                      object
                  Security Context:
                    Description:  The securityContext which should be set on non-privileged pods. All pods which require privileged permissions will still require a privileged securityContext.
                    Properties:
                      Enabled:
                        Description:  Whether a securityContext should be set on the pod. In cases where no PSPs are applied to the cluster, this is not necessary.
                        Type:         boolean
                      Fs Group:
                        Description:  A special supplemental group that applies to all containers in a pod.
                        Format:       int64
                        Type:         integer
                      Run As Group:
                        Description:  The GID to run the entrypoint of the container process.
                        Format:       int64
                        Type:         integer
                      Run As User:
                        Description:  The UID to run the entrypoint of the container process.
                        Format:       int64
                        Type:         integer
                    Type:             object
                Type:                 object
              Use Etcd Operator:
                Description:  UseEtcdOperator specifies whether the metadata service should use etcd for storage.
                Type:         boolean
              Version:
                Description:  Version is the desired version of the Vizier instance.
                Type:         string
            Type:             object
          Status:
            Description:  VizierStatus defines the observed state of Vizier
            Properties:
              Checksum:
                Description:  A checksum of the last reconciled Vizier spec. If this checksum does not match the checksum of the current vizier spec, reconciliation should be performed.
                Format:       byte
                Type:         string
              Last Reconciliation Phase Time:
                Description:  LastReconciliationPhaseTime is the last time that the ReconciliationPhase changed.
                Format:       date-time
                Type:         string
              Message:
                Description:  Message is a human-readable message with details about why the Vizier is in this condition.
                Type:         string
              Reconciliation Phase:
                Description:  ReconciliationPhase describes the state the Reconciler is in for this Vizier. See the documentation above the ReconciliationPhase type for more information.
                Type:         string
              Sentry DSN:
                Description:  SentryDSN is key for Viziers that is used to send errors and stacktraces to Sentry.
                Type:         string
              Version:
                Description:  Version is the actual version of the Vizier instance.
                Type:         string
              Vizier Phase:
                Description:  VizierPhase is a high-level summary of where the Vizier is in its lifecycle.
                Type:         string
              Vizier Reason:
                Description:  VizierReason is a short, machine understandable string that gives the reason for the transition into the Vizier's current status.
                Type:         string
            Type:             object
        Type:                 object
    Served:                   true
    Storage:                  true
    Subresources:
      Status:
Status:
  Accepted Names:
    Kind:       Vizier
    List Kind:  VizierList
    Plural:     viziers
    Singular:   vizier
  Conditions:
    Last Transition Time:  2022-08-17T10:01:22Z
    Message:               no conflicts found
    Reason:                NoConflicts
    Status:                True
    Type:                  NamesAccepted
    Last Transition Time:  2022-08-17T10:01:22Z
    Message:               the initial names have been accepted
    Reason:                InitialNamesAccepted
    Status:                True
    Type:                  Established
  Stored Versions:
    v1alpha1
Events:  <none>

kubectl describe vizier pixie -n pl

kubectl describe vizier pixie -n pl
Error from server (NotFound): viziers.px.dev "pixie" not found

installation was successful, following this document
https://docs.px.dev/installing-pixie/install-guides/airgap-pixie/


Different build paths for Xcode 8 and 9

Hi there,
I'm looking for an option to build and upload different xcode-version builds of the same framework into the same bucket.
This might be possible by storing different buildtypes in subpaths in the same buckets and up-/downloading with a configuration path like:
rome upload --buildpath DEFINED_IN_ROMEFILE
rome download --buildpath DEFINED_IN_ROMEFILE
The buildpath could simply be defined within the romefile.
Does a similar feature already exist?
**Rome version:** latest
**OS and version:** macOS 10.12.5

Cheers

Hi, @Zeotyn
thanks for opining an issue.
This feature does not exist at the moment. I'm assuming that what you really want is not the Xcode Version but rather the Swift version. Is that correct?

Sounds great! I meant Swift versions, sorry.

@Zeotyn Please try pre-release https://github.com/blender/Rome/releases/tag/v<IP_ADDRESS>
Please report any bugs, if it works as intended I will make a full release.

The prefix doesn't seem to be consistently applied to the local cache path. It's used for lookup but the downloaded files are not copied to the right location yet:
▸ Error: could not find quick.dSYM in local cache at : /Users/fhqwhgads/Library/Caches/Rome/Xcode9/quick/iOS/quick.framework.dSYM-v1.1.0.zip
▸ Downloaded quick.dSYM from: Xcode9/quick/iOS/quick.framework.dSYM-v1.1.0.zip
▸ Copied quick.dSYM to: /Users/fhqwhgads/Library/Caches/Rome/quick/iOS/quick.framework.dSYM-v1.1.0.zip

@kaybutter thanks, I'll check. I think it might be just a an error in the logs.

Nope. It actually overwrote the old cache, that's how I noticed.

Good catch,
please try https://github.com/blender/Rome/releases/tag/v<IP_ADDRESS>

@blender great and very fast thanks!
▸ Error: could not find quick in local cache at : /Users/mobileadmin/Library/Caches/Rome/Xcode9/quick/iOS/quick.framework-v1.1.0.zip
▸ Downloaded quick from: Xcode9/quick/iOS/quick.framework-v1.1.0.zip
▸ Copied quick to: /Users/mobileadmin/Library/Caches/Rome/Xcode9/quick/iOS/quick.framework-v1.1.0.zip

@Zeotyn @kaybutter no problem. I'll test a little more and then make a full release via brew

FYI don't you that tag there is one more bug when uploading .version files.  Wait for the full release. It will happen shortly

New version is out:
get it at https://github.com/blender/Rome/releases/tag/v<IP_ADDRESS> or run brew update rome


Integrate lightning_utilities==0.4.2

What does this PR do?
Fixes https://github.com/Lightning-AI/utilities/issues/57
Does your PR introduce any breaking changes? If yes, please list them.
None
cc @borda

This is blocked by #15786

Now blocked by https://github.com/Lightning-AI/lightning/pull/15454. Will try to remove this circular dependency in this PR


Use a SIDECAR_VERSION by default for the reported version

Apparently there's no env_or_default, option_env!() exists, but it's not fine with concat!(), ... :-)

Codecov Report
Attention: Patch coverage is 83.33333% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 67.85%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #457      +/-   ##
==========================================
- Coverage   67.85%   67.85%   -0.01%
==========================================
  Files         193      193
  Lines       24601    24615      +14
==========================================
+ Hits        16694    16702       +8
- Misses       7907     7913       +6

Components
Coverage Δ

crashtracker
19.34% <ø> (ø)

datadog-alloc
98.76% <ø> (ø)

data-pipeline
51.45% <ø> (ø)

data-pipeline-ffi
0.00% <ø> (ø)

ddcommon
85.24% <ø> (ø)

ddcommon-ffi
74.93% <ø> (ø)

ddtelemetry
56.09% <ø> (ø)

ipc
81.69% <ø> (-0.11%)
:arrow_down:

profiling
78.09% <ø> (ø)

profiling-ffi
60.05% <ø> (ø)

serverless
0.00% <ø> (ø)

sidecar
37.89% <83.33%> (+0.21%)
:arrow_up:

sidecar-ffi
0.00% <ø> (ø)

spawn-worker
54.98% <ø> (ø)

trace-mini-agent
69.12% <ø> (ø)

trace-normalization
97.79% <ø> (ø)

trace-obfuscation
95.74% <ø> (ø)

trace-protobuf
30.76% <ø> (ø)

trace-utils
78.29% <ø> (ø)


Please update tsutils to ^2.27.2

<EMAIL_ADDRESS>has fixes for breaking changes in the TypeScript@3 API. https://github.com/ajafff/tsutils/issues/71

done in 4.0


Refactor settings & improve dx

This PR aims to:

Expose Settings for ScalaCLI so it does not need to instantiate Context and can discover settings & categories. (1)
Get rid of mutable state within Settings, so we can create an immutable DSL for implementing options like -W ("-Wall") (2)
Standardise parsing & structure of the settings. (3)
Refactor the settings to prevent problems in the future. (4)

Goals
Here is the additional context for each of the goals:
(1) Exposing Settings
ScalaSettings was a class that was instantiated for each compiler context. Each time it was the same - the state was (almost) separated from it and put in SettingsState. Due to it being a class, tooling needed an artificial compilation context to access the fields. Even after acquiring this ScalaSettings instance, the settings did not expose API with the required access paths: (provided by ScalaCLI team)

List of all keys accepted by the Compiler
List of categories prefixes (-V, -W, etc.)
List of keys not requiring source inputs
List of alises for keys / access to keys via aliases
Way to determine how a setting accepts options (after : or space?)
Way to see if settings are a flag.
Way to see if a setting can be provided multiple times.

Additionally, the ScalaSettings were the same each time and represented a static structure - it would lower complexity & limit potential problems if made an immutable object instead.
(2) Mutable state
Settings still had a piece of mutable state inside of them - it was used to store a flag denoting whether the setting was set repeatedly. It could be stored in SettingsState instead, allowing an immutable DSL on Settings.
(3) Standarisation
Settings contain some behaviors that may be hard to get right without preexisting knowledge. They do not have a standard enforced upon them. That causes two problems:

It may be misleading to users & worsen the DX
It was reported as a cause of problems in integration with ScalaCLI and may cause similar problems in the future for other tools

These problems include:

Some options support only passing parameters after a semicolon, and some allow passing them after space: Strings/Ints allow after space, VersionTags/Files/Lists do not, etc, and there's no way to know which is which without trying it out
Some have -- aliases, some don't

(4) Refactor
Mutable state in Settings, various ways of handling Setting values (like -Ykind-projector), no validation of settings names/states, no way of enforcing categories in settings were all problems that caused a handful of constructs that made it harder to work with settings. I recognized that it was a good moment to refactor the code & enforce some rules and patterns.
Solutions
(1) Exposing Settings

Made ScalaSettings an immutable public object (made Setting immutable alongside)
Added methods allowing access to required data
Added categories to Setting and made prefix Optional for discoverability

The requirement of checking if provided options run help instead of requiring source can be done by passing now immutable ScalaSettings and SettingsState to ScalacCommand isHelpArg
(2) Mutable state
changed field was moved to SettingsState as a Set instead of storing it as a mutable field in the Setting. Now Setting describes the structure of settings, and the whole state is represented by SettingsState. The plan is to use this property for a similar goal as the "post set hooks" in Scala 2 (aside from exposing the API)
(3) Standarisation

All options can now be passed with either -- or -. There are some exceptions that come from aliases kept for backward compatibility.
Setting names are now validated against simple regex [a-zA-Z0-9_\\-]*
Setting names are now validated so they do not contain - at the beginning and contains category prefix (like W)
All arguments can now be passed after space or :. -Ykind-projector is an exception that was kept for backward compatibility. Set of additional rules was introduced for the settings to make sure that nothing breaks and compatibility is kept:

Empty strings are not supported as choice arguments. They were not supported for any other parameter type, only for String parameters that accept a set of choice values. If an empty choice setting was allowed, passing no value would result in empty value being chosen. Example: -Ykind-projector accepts parameters: -Ykind-projector:underscores. But if it was passed as just -Ykind-projector, then the value would be set to an empty string. This feature made it hard to keep backward compatibility after making it possible to pass arguments for every type of setting after a space: One could write -Ykind-projector Main.scala and mistakenly pass Main.scala as an arg for the setting. Luckily,  Ykind-projector is the only setting that used this feature and is kept as legacy, no new settings with this behavior are allowed.
List settings cannot accept ignore invalid args. Luckily, no setting was doing that. If possible, an existing command that works but produces a warning like -foo Main.scala (for-foo accepting list of string args) would stop working. String commands did accept passing arguments after space before, but this is a new behavior for the list settings. If ignoring invalid args was possible, commands like -foo Main.scala could work unexpectedly.

(4) Refactor
It's mostly visible in the sources. For example, there is no need to change classfileVersion in two places every time.
Additional changes
-Xlint was deprecated in favor of -Wshadow, as it was only used for shadow warnings in the current shape. It's TBD, but from my perspective, there is no point in keeping some warnings as args for -Xlint, and some as separate -W settings.

@lrytz I will write detailed description before making it ready for review

Thanks, what you added is already really helpful!

Nice description, @szymon-rd !

TODO: Run full open CB on this

Some projects in CB failed. After investigation, I found the cause: Some macro libraries, especially Enumeratum, use ScalaSettings directly from the compiler. I think we should be able to have a ScalaSettings trait & companion object implementing it and fix it with it.

Please do not merge yet, I am still validating community builds.

There seems to be a last problem: Some project in CB B failed with
Error:  missing argument for option -Xmigration
It seems to be the last problematic option

thorough writeup in PR description much appreciated 👍


cmd/cue: circular module dependency unexpectedly allowed

What version of CUE are you using (cue version)?

$ cue version
cue version v0.0.0-20221124131431-525648d853bb

       -compiler gc
     CGO_ENABLED 1
          GOARCH arm64
            GOOS linux
             vcs git
    vcs.revision 525648d853bb7dbb9187bff2649c03db8d865be8
        vcs.time 2022-11-24T13:14:31Z
    vcs.modified false

Does this issue reproduce with the latest release?
Yes
What did you do?
! exec cue export ./z
stderr 'circular module dependency'

-- cue.mod/module.cue --
module: "mod.com/x"
-- cue.mod/pkg/example.com/y/y.cue --
package y

import "mod.com/x"

Y: x.X
-- x.cue --
package x

X: 5
-- z/z.cue --
package z

import "example.com/y"

Z: y.Y

What did you expect to see?
A passing test (modulo the precise error message matching with stderr)
What did you see instead?
# Not clear that we want to support circular module dependencies
# which is what is implied by this setup. (0.029s)
> ! exec cue export ./z
[stdout]
{
    "Z": 5
}
FAIL: /tmp/testscript2569518014/repro.txtar/script.txtar:3: unexpected command success

I've seen this pattern a number of times in user code.
I'm not clear we should support circular module dependencies (at this time). At least until we have a clearer picture of how this would/wouldn't work in modules part II.
Fixing this would (I believe) require us to make a breaking change preventing any package within the cue.mod/  vendor importing a package from the main module.

cc @rogpeppe for modules.

Chatting with @mpvl it's not clear there is merit in breaking people who are relying on this today. Whether people are intentionally creating a circular module dependency is a separate question, and per @mvdan one we can warn/similar during the transition from vendor-based modules to modules "proper".


Cannot install, got composer error

hello, im cant install your package on laravel i was also got message about:
  Problem 1
    - Root composer.json requires spatie/laravel-model-flags ^1.1 -> satisfiable by spatie/laravel-model-flags[1.1.0].
    - spatie/laravel-model-flags 1.1.0 requires spatie/laravel-package-tools ^1.13.6 -> found spatie/laravel-package-tools[1.13.6] but the package is fixed to 1.12.1 (lock file version) by a partial update and that version does not
match. Make sure you list it as an argument for the update command.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
You can also try re-running composer require with an explicit version constraint, e.g. "composer require spatie/laravel-model-flags:*" to figure out if any version is installable, or "composer require spatie/laravel-model-flags:^2.1
" if you know which you need.

Is after deletion spatie/laravel-activitylog
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires spatie/laravel-model-flags ^1.1 -> satisfiable by spatie/laravel-model-flags[1.1.0].
    - spatie/laravel-model-flags 1.1.0 requires illuminate/contracts ^9.0 -> found illuminate/contracts[v9.0.0-beta.1, ..., 9.x-dev] but these were not loaded, likely because it conflicts with another require.

You can also try re-running composer require with an explicit version constraint, e.g. "composer require spatie/laravel-model-flags:*" to figure out if any version is installable, or "composer require spatie/laravel-model-flags:^2.1
" if you know which you need.

I could install the package together with Laravel Activity in a fresh Laravel project, so I guess this is caused by something specific to your project.
Feel free to submit a PR should you find that our dependencies can be improved.

I could install the package together with Laravel Activity in a fresh Laravel project, so I guess this is caused by something specific to your project.
Feel free to submit a PR should you find that our dependencies can be improved.

i can also install your another libraries like model tags, but this not  working


SecurityPolicyDsc: Resolved custom Script Analyzer rules

Pull Request (PR) description

Changes to SecurityPolicyDsc

Resolved custom Script Analyzer rules that was added to the test framework.

This Pull Request (PR) fixes the following issues

Task list

[ ] Added an entry under the Unreleased section of the change log in the README.md.
Entry should say what was changed, and how that affects users (if applicable).
[ ] Resource documentation added/updated in README.md.
[ ] Resource parameter descriptions added/updated in README.md, schema.mof
and comment-based help.
[ ] Comment-based help added/updated.
[ ] Localization strings added/updated in all localization files as appropriate.
[ ] Examples appropriately added/updated.
[ ] Unit tests added/updated. See DSC Resource Testing Guidelines.
[ ] Integration tests added/updated (where possible). See DSC Resource Testing Guidelines.
[ ] New/changed code adheres to DSC Resource Style Guidelines and Best Practices.

This change is

@jcwalker Can you review and merge this. Resolves an issue before we merge a new custom rule in the test framework.

Codecov Report

Merging #136 into dev will not change coverage.
The diff coverage is 100%.

@@        Coverage Diff         @@
##           dev   #136   +/-   ##
==================================
  Coverage   89%    89%
==================================
  Files        5      5
  Lines      498    498
==================================
  Hits       447    447
  Misses      51     51


Broken Link from Privacy Policy to return in homepage

once the privacy policy is opened from the Contact Form, if the user clicks on the homepage banner on top, a white/blank page opens. Video attached with details
https://user-images.githubusercontent.com/70584713/141294068-13268b8d-db54-4f19-b22a-b77a846f889e.mov

presente su develop

closed by #168


'set-script' isn't working with older versions of npm.

Hi Mr. Mohamed,
Thanks for creating this package, I found it a helpful one.
I had an issue while creating a new project using your tool with a log  Whoops!, Sir... 😂💔 but Command failed: npm set-script start:dev "nodemon --watch './**/*.ts' --exec 'ts-node' ./src/index.ts.
It seems that the set-script command requires at least npm v7.x and my npm version was 6.x, I updated npm to the latest version and everything went fine.
I just hope for your error message to be more declarative if you could check the npm version.
Thanks for your understanding ^^

Dear
thanks for your message
will check it and update the error message in the next release
thanks for using the package
stay safe ❤


Possible to write output directly to stdout?

This is on Windows, btw, if that matters.
I'm basically trying to run a console command via gulp, and want to see the output from it printed in the terminal just as if I'd run the command directly.  It looks like I can do this by using run.Command but I actually want to do it via gulp.  Apologies if this is a basic question, I actually have very little experience with streams outside of gulp boilerplate.
I've tried doing something like
gulp.task('serve', function() {
    return run('polymer serve -o').exec()
        .pipe(process.stdout);
});

But that just throws an error saying "TypeError: Invalid data, chunk must be a string or buffer, not object"
So far, it looks like one solution is to use gulp.dest('path/to/output') and then some more code that reads that output file and outputs it to stdout, but I'm pretty sure that would remove any ANSI color coding that might be included, which is a disadvantage.
So, is there any super-obvious I-should-have-already-seen-this solution to this?

Yep, this was definitely a super-obvious I-should-have-already-seen-this solution - just pass an options object with 'verbosity':3 to the run commands.  In my defense, all of the things I've tested with this have required ctrl-c'ing to quit the process, which seems to prevent the default verbosity level from ever displaying anything.


Ensure URI #fragments are stripped from URIs, and test for this

At present, it appears URI fragments are being sent to the server, when they should be known only to the client. We should strip them out.

@cgiffard I added a test in https://github.com/cgiffard/node-simplecrawler/commit/ca9bef627f3d5359a415068fb99284997f2945b2, and it seems fragment identifiers are being stripped already.

Cool. I'll close this issue! :)


Text wrapping/alignment doesn't survive resize (portrait to landscape mode)

I'm finding if my text is nicely aligned right and spans multiple lines (due to wrapping) in portrait mode it will draw partially offscreen in landscape mode.

This seems to be related to word wrapping - if I happen to wrap in the landscape mode everything lines up fine.  If I don't - the text is on a single line - the text goes offscreen.

Discussed with @apwilson and we weren't sure how to reproduce the issue.  Please re-open if this happens again.


Python context retains imported modules after reset

From @devhoffmann: To reproduce: import some python module via the code editor widget and call an included function run the snippet comment out the import statement run the snippet
Outcome: Although the module is not imported the second time, it is somehow still loaded by pybind and no error is thrown
@swallat: we should take a look at this

Fixed with #46


The graphs need some retouches

[ ] The resolutions are completely off: the text is tiny compared to the bars or the bars are just way too big.

[ ] The graphs can show the ratio between the total files and the complex files, on the y axis you put the percentage so all the bars are at the same level (100%) and it is easy to see if the project is getting more complex over time.

I'm looking forward to see the analysis on functions, you may also plot them weighted by their loc.

FIxed resolution and bar size
Now the graph show the ratio as requested


Create runtime.txt

Heroku auto builds this in python3.x evnironment.
In python3 app fails on start with:
2017-10-15T15:15:39.481094+00:00 app[web.1]:   File "manage.py", line 4, in
2017-10-15T15:15:39.481198+00:00 app[web.1]:     from app import app, db, setup_all
2017-10-15T15:15:39.481214+00:00 app[web.1]:   File "/app/app.py", line 51
2017-10-15T15:15:39.481215+00:00 app[web.1]:     except Exception, e:
2017-10-15T15:15:39.481234+00:00 app[web.1]:                     ^
2017-10-15T15:15:39.481247+00:00 app[web.1]: SyntaxError: invalid syntax
With this config file app is correctly built and starts.
EDIT: If you are adding this file on existing project you need to add the file to git and push new commit with a file to heroku.

Having the same issue

change all the except Exception, e :   to   except Exception as e :
I think the problem is due to python version , I got the same problem .
@mayukh18 can you please tell us which version of python are you using ?

@utkarshkvs1 He is using python 2.x, you can see that from the syntax. For some time now Heroku builds python apps in python 3.x. This is why I added config file so Heroku can recognize that this app needs to be built in python 2.x environment. :)
@calvinti12 just add this file to your cloned directory and it will work

thanks @capJavert for help , can you tell how to install requirements for python2 while having python3 as default.
the command pip install -r requirements.txt install the modules for default version of python .

getting the same issue even after adding runtime.txt
2017-10-20T15:17:54.661934+00:00 heroku[web.1]: Starting process with command python manage.py runserver --host <IP_ADDRESS> --port ${PORT}`
2017-10-20T15:17:58.601697+00:00 heroku[web.1]: Process exited with status 1
2017-10-20T15:17:58.439795+00:00 app[web.1]: Traceback (most recent call last):
2017-10-20T15:17:58.439821+00:00 app[web.1]:   File "manage.py", line 4, in
2017-10-20T15:17:58.440018+00:00 app[web.1]:     from app import app, db, setup_all
2017-10-20T15:17:58.440040+00:00 app[web.1]:   File "/app/app.py", line 51
2017-10-20T15:17:58.440059+00:00 app[web.1]:     except Exception, e:
2017-10-20T15:17:58.440086+00:00 app[web.1]:                     ^'

@utkarshkvs1 did you added runtime.txt file to git and commited, pushed to origin/heroku?

@capJavert
I've commited the changes to my repository
but now It's showing
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 756 bytes | 0 bytes/s, done.
Total 7 (delta 3), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Python app detected
remote:  !     The latest version of Python 3 is python-3.6.2 (you are using +python-2.7.14, which is unsupported).
remote:  !     We recommend upgrading by specifying the latest version (python-3.6.2).
remote:        Learn More: https://devcenter.heroku.com/articles/python-runtimes
remote: -----> Found python-3.6.2, removing
remote: -----> Installing +python-2.7.14
remote:  !     Requested runtime (+python-2.7.14) is not available for this stack (heroku-16).
remote:  !     Aborting.  More info: https://devcenter.heroku.com/articles/python-support
remote:  !     Push rejected, failed to compile Python app.
remote:
remote:  !     Push failed
remote: Verifying deploy...
remote:
remote: !	Push rejected to blindchat9211.
remote:
To https://git.heroku.com/blindchat9211.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.heroku.com/blindchat9211.git'
Please help

Thanks @capJavert for pointing this out. It indeed seems heroku builds have changed. However, as @utkarshkvs1 said the runtime.txt did not solve the problem. Yes I pushed it after commit. Are we missing something here?

@utkarshkvs1 can you lead us to how you got this?

replying to @mayukh18
I got this when I tried to deploy the app to heroku using git push heroku master after commiting the changes suggested by @capJavert

Seems to be some anomaly @utkarshkvs1 because it's working fine.


Add OOTB cluster role binding to Aqua community operator.

Thanks submitting your Operator. Please check below list before you create your Pull Request.
New Submissions

[ ] Does your operator have nested directory structure?
[ ] Have you selected the Project Community Operator Submissions in your PR on the right-hand menu bar?
[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?

[ ] Have you tested your Operator in all supported installation modes?
[ ] Have you considered whether you want use semantic versioning order?
[ ] Is your submission signed?
[ ] Is operator icon set?

Updates to existing Operators

[ ] Did you create a ci.yaml file according to the update instructions?
[ ] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[ ] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[ ] Have you tested an update to your Operator when deployed via OLM?
[ ] Is your submission signed?

Your submission should not

[x] Modify more than one operator
[x] Modify an Operator you don't own
[x] Rename an operator - please remove and add with a different name instead
[x] Submit operators to both upstream-community-operators and community-operators at once
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[ ] Description about the managed Application and where to find more information
[ ] Features and capabilities of your Operator and how to use it
[ ] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[ ] Human readable name and 1-liner description about your Operator
[ ] Valid category name1
[ ] One of the pre-defined capability levels2
[ ] Links to the maintainer, source code and documentation
[ ] Example templates for all Custom Resource Definitions intended to be used
[ ] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

hey @J0zi  @mvalarh
the PR failed the tests because the operator is already published (need re-written).
any way to bypass it ?

hey @J0zi  @mvalarh
the PR failed the tests because the operator is already published (need re-written).
any way to bypass it ?

/ok-to-test

/ok-to-test

/test deploy-operator-on-openshift

/test deploy-operator-on-openshift