Plans on adding a filter?

Hi Adrian,
Awesome work! Have been sharing this far and wide!
Do you have plans on adding a filter to saasforcovid?
Reason: I was planning to create a local non-saas version of your project, but given the range of things I'd be listing I absolutely need a filter. I'd like to get a "no-drop down" type of filter in place. I've mocked up what I want to implement in the picture below (i.e. the filter would be always visible in full on the top of the screen, above the list of "posts", in  your case above the list of Saas products ).
So the question is: Do you intend implement a filter?
If not, would you be able to suggest how I'd implement it myself (not exactly a full-stack dev here:) )?

Once again, thanks for this good work! 👏🏻
PS: apologies for the horrendous choice of filter colors (didn't spend much time making a color palette for above sketch... ) and misalignment

Would love to have a filter and I'm happy to guide you in the right direction! I don't have more time for saasforcovid.com at the moment, so feel free to add a PR.
You want to update this function to filter entries:
https://github.com/adriaanvanrossum/saasforcovid.com/blob/9f227c607a383dae78b4c55430845cee3de24ca5/src/App.vue#L538-L541
Every entry has more or less these fields:
{
  name: "Digital Ocean",
  approved": "Yes",
  category": "Hosting",
  url: "https://digitalocean.com",
  ...
}

To filter on the results you could do something like this:
.filter(({ description, name, category }) => {
  if (!description || !name || !category) return false;
  if (this.category) return category === this.category;
  return true
})

Make sure to add category to the data object:
https://github.com/adriaanvanrossum/saasforcovid.com/blob/9f227c607a383dae78b4c55430845cee3de24ca5/src/App.vue#L514-L524
When this is done you can test it with setting a category manually.
After that works you can add fields above the page to show the filters. You can either do this by input field or by preset categories.
Let me know if you need any help.

Thanks a ton @adriaanvanrossum for the guidance! Really appreciated!
Following up:
A couple of questions as I explore:

On the data object:
https://github.com/adriaanvanrossum/saasforcovid.com/blob/9f227c607a383dae78b4c55430845cee3de24ca5/src/App.vue#L514-L524

Apologies, but what do you mean with adding category to the data object? In which way should I do that?:
data() {
     return {
       json: services,
       error: null,
       services: [],
       loading: true,
       buildDate: BUILD_DATE ? format(BUILD_DATE) : null,
       commitHash: COMMIT_HASH,
       show: ["maybe", "no"],
     };
   },

Tried to test early filtering by making a copy of your google sheet and before anything else checking if changes in my sheet would render on the UI. I've then update-cache.js changed it to my Google sheet URL in here:
https://github.com/adriaanvanrossum/saasforcovid.com/blob/d287e9fcee340fbaa30fdaf22b5e9df9d032ad0e/lib/update-cache.js#L5
and then setting up the two github actions workflow files you have.
https://github.com/adriaanvanrossum/saasforcovid.com/blob/master/.github/workflows/deploy.yml
and https://github.com/adriaanvanrossum/saasforcovid.com/blob/master/.github/workflows/update-cache.yml

Despite that, if I do changes to the Google sheet, cache.js does not update itself, so the UI does not change. Any pointers of what I may be doing wrong?
(Before anything, I've also double-checked that the downloaded CSV from Google sheets is being modified as changes are made to the google sheet, so the csv is ok, but the .get(SHEET) does not seem to be working.)
Hope those were clear, otherwise, please let me know and I'll revert asap.
Thanks a ton!

How about this?

data() {
  return {
    json: services,
    error: null,
    services: [],
    loading: true,
    buildDate: BUILD_DATE ? format(BUILD_DATE) : null,
    commitHash: COMMIT_HASH,
    show: ["maybe", "no"],
    category: null,
  };
},

What is going wrong with deploying to GitHub Pages?

Thanks for reverting @adriaanvanrossum
Following up:

What is going wrong with deploying to GitHub Pages?

Github pages places relative paths on index.html in the gh-pages branch. So all css files and js files are not found if one is deploying the project using Github page's "github.io" free URLs. I've been able to fix this by deleting the first "/" from the path of all css and js files linked to index.html in the gh-pages branch. This however isn't permanent, given any new deployment (following a github action) again makes the index.html add a "/" to the css and js links and the app again won't render.
I'm unsure of where this could be fixed in your project. Anyways, this is a non-issue should one use a custom domain, all links to the css files and js files work perfectly that way and the app renders.
This is the line in your project:
https://github.com/adriaanvanrossum/saasforcovid.com/blob/f837c0a1ddce24429410e68c682a0b6cba3e3ac2/index.html#L12

Back to the filters:

How about this?

data() {
  return {
    json: services,
    error: null,
    services: [],
    loading: true,
    buildDate: BUILD_DATE ? format(BUILD_DATE) : null,
    commitHash: COMMIT_HASH,
    show: ["maybe", "no"],
    category: null,
  };
},

This plus the filters made filtering work. I've tested by forcing a category (in this case "Recruitment"):
data() {
  return {
    json: services,
    error: null,
    services: [],
    loading: true,
    buildDate: BUILD_DATE ? format(BUILD_DATE) : null,
    commitHash: COMMIT_HASH,
    show: ["maybe", "no"],
    category: "Recruitment",
  };
},

And things were working perfectly given I could filter by paid/free/maybe AND then filter by a category, (in this case "Recruiting"). Exactly the behaviour I wanted. Having said that, I'm now stuck with making it work for a filter chosen in the UI.
i.e. from choosing it from the list of categories in the UI does not filter anything:

--> link to the UI (but may stop and you'd get a blank page once a a new github action runs / see my comment above about relative paths): https://codeconomy.github.io/codeconomy.github.io-list/
I have been attempting a few things to tie the filter selection to what is returned by showServices but haven't been lucky.
I'd welcome any pointers :)
Thanks a lot again!

I have been attempting a few things to tie the filter selection to what is returned by showServices but haven't been lucky.
I'd welcome any pointers :)

Managed to get it to work. 🙌🏼 Will prepare add PR. disclaimer: very non-DRY code ...
Opening a new issue in a second to ask whether you have a suggestion to generate unique pages to each of the listings according to a template (i.e. not linking out to the different SaaS products (in your case), but to pages in saasforcovid.com that would offer more details about each saas product.)
Thanks a lot for all the help @adriaanvanrossum

You did a great job! DRY is not important. People using the product wouldn't know :)
It seems like two categories are not working at the moment:

Thanks for testing @adriaanvanrossum ! :)
Just saw the typo leading to it. Will send a PR.


Cannot restart avahi-daemon

FreeBSD% sudo service avahi-daemon restart
Stopping avahi-daemon.
Starting avahi-daemon.

FreeBSD% sudo service avahi-daemon status
avahi_daemon is not running.

FreeBSD% sudo avahi-daemon
Found user 'avahi' (UID 558) and group 'avahi' (GID 558).
Successfully dropped root privileges.
avahi-daemon 0.7 starting up.
Loading service file /usr/local/etc/avahi/services/sftp-ssh.service.
Loading service file /usr/local/etc/avahi/services/ssh.service.
*** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
bind() failed: Address already in use
*** WARNING: Detected another IPv6 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
bind() failed: Address already in use
Failed to create server: No suit

We have
/usr/local/etc/avahi/services/sftp-ssh.service
/usr/local/etc/avahi/services/ssh.service

Announcing services to the network no matter whether sshd is actually running or not is kinda braindead and defeats the purpose of Zeroconf, isn't it?


Executables with other-modules end up with incorrect paths

I have:
executable analyse-quoting
  ...
  other-modules:
    CircuitHub.Quoting.Analysis.AssemblyPricing.Picofactory2
    CircuitHub.Quoting.Analysis.CompetitorQuote
    CircuitHub.Quoting.Analysis.FinalOffers
    CircuitHub.Quoting.Analysis.QuoteParameters
    CircuitHub.Quoting.Analysis.Report
    CircuitHub.Quoting.Analysis.Sample

But when I run gen-hie I get:
    - path: "./quoting/exe-analyse-quoting/Main.hs"
      component: "quoting:exe:analyse-quoting"

    - path: "./quoting/exe-analyse-quoting/CircuitHub.Quoting.Analysis.AssemblyPricing.Picofactory2.hs"
      component: "quoting:exe:analyse-quoting"

    - path: "./quoting/exe-analyse-quoting/CircuitHub.Quoting.Analysis.CompetitorQuote.hs"
      component: "quoting:exe:analyse-quoting"

    - path: "./quoting/exe-analyse-quoting/CircuitHub.Quoting.Analysis.FinalOffers.hs"
      component: "quoting:exe:analyse-quoting"

    - path: "./quoting/exe-analyse-quoting/CircuitHub.Quoting.Analysis.QuoteParameters.hs"
      component: "quoting:exe:analyse-quoting"

    - path: "./quoting/exe-analyse-quoting/CircuitHub.Quoting.Analysis.Report.hs"
      component: "quoting:exe:analyse-quoting"

    - path: "./quoting/exe-analyse-quoting/CircuitHub.Quoting.Analysis.Sample.hs"
      component: "quoting:exe:analyse-quoting"

Which is wrong - these files don't exist.

@ocharles hi! did you have the chance to check if the patch worked for you?


aio-studi-and-thesis:0.1.0

I am submitting

[x] a new package
[ ] an update for a package

Description:
With this unofficial template, students can easily create documentation or a thesis without having to create the layout themselves. It is highly customisable when it comes to tables of contents, tables of figures, etc. The colours, font colour, adjustments to the tables of contents etc. can be made in one central location. It can be used in both German and English. The cover page and the explanation can be easily exchanged if required. If a special table of contents is missing, it can simply be inserted so that it is in the right place. This saves a lot of time, especially when professors at a university are constantly making new demands on the design of the document.

I have read and followed the submission guidelines and, in particular, I

[x] selected a name that isn't the most obvious or canonical name for what the package does
[x] added a typst.toml file with all required keys
[x] added a README.md with documentation for my package
[x] have chosen a license and added a LICENSE file or linked one in my README.md
[x] tested my package locally on my system and it worked
[x] excluded PDFs or README images, if any, but not the LICENSE

[x] ensured that my package is licensed such that users can use and distribute the contents of its template directory without restriction, after modifying them through normal use.

https://github.com/typst/packages/pull/845
I had previously opened a pull request, but it didn't work because the thumbnail wasn't the right size. Now I had to enlarge it. I hope this was the right approach :)

I think you could have just pushed another commit to your previous PR, but re-doing it works as well :) Thanks!

@elegaanz Thank you very much and especially that it went so quickly :)


Switch to mocha-phantomjs-core and system PhantomJS

This switches to the more lightweight mocha-phantomjs-core project that allows us to use system PhantomJS, which should be the later 2.x series rather than 1.9.
/cc @dgraham

Hmm seems like Travis CI still has PhantomJS on 1.9.8. But at least locally you're free to test on whatever is the system version. Passes for me on 2.1.1

:shipit:


Localization update

This PR was auto-generated with the localization pipeline build.

Closed as there are no relevant changes


nifi-reg import-flow-version must not require the --flowVersion argument

This is quite counterintuitive. We should be either using the flow version from the definition file or default to latest on import, i.e. append-only mode. Also, version counts will not necessarily match between buckets/instances, e.g. Dev & Prod, so requiring this arg is not right.

I agree, I think it should just become the next one up number. Since we don't have a true import on the registry side, we can just make a call to determine the latest version number of the flow we are importing to, and then make the imported version be the next one-up number. Will work on this.


Some issues testdriving

Hey,
first of all, thanks for this, it's very promising and just what I need. Some issues though, they might be a result of the incomplete documentation, but I could not figure them out.
First of all, here's the what I'm using
local function cardmenu()
  local impromptu = require("impromptu")

  local opts = ...

  impromptu.core.ask{
    question = "Navigate over the tree",
    options = opts,
    handler = function(_, opt)
      print(opt)
      return true
    end
  }
end

This seems to work. However, adding
local opts = {
  Aux = {
    description = "Auxiliaries",
    key = "A",
    children = {
      GRP = { description = "Group" },
      CDATA = { description = "Cdat", item = "asdf" }
    }
  },
}

results in an error, because on line 75 of init.lua, h is a nil value. Using the following makes the error go away:
local opts = {
  Aux = {
    description = "Auxiliaries",
    key = "A",
    children = {
      GRP = { description = "Group" },
      CDATA = { description = "Cdat", item = "asdf" }
    }
  },
  one = {
    description = "Item 1",
    key = "X",
    children = {
      eleven = {description = "Item 11"},
      twelve = {description = "Item 12"},
    }
  },
}

so it seems connected to the number of options or something.
Now the menu is basically working, but:

A is not used as a key for the first menu, but r (also, "X" isn't the key for "Item1").
The order of the items is different than in the options table. That's surprising. How can I influence the ordering?
When going down to the CDATA item, the handler actually prints CDATA, while it should print asdf.

Also, could you point out what I can do with the "session" object in the handler? It might be what I need... actually, I might need the "breadcrumbs" mentioned here.
As far as docs go, could you explain why in this code the item child is not a leave value? Or did I misinterpret it?
Thanks again :)

Oh, this is a tad longer, but using
local opts = {
  Aux = {
    description = "Auxiliaries",
    key = "A",
    children = {
      cd={ description = "cd.inc" },
      de={ description = "de.inc" },
      fc={ description = "fc.inc" },
      fm0={ description = "fm0.inc" },
      fm1={ description = "fm1.inc" },
      fm2={ description = "fm2.inc" },
      fm3={ description = "fm3.inc" },
      fm4={ description = "fm4.inc" },
      fm5={ description = "fm5.inc" },
      fr1={ description = "fr1.inc" },
      fr10={ description = "fr10.inc" },
      fr11={ description = "fr11.inc" },
      fr12={ description = "fr12.inc" },
      fr13={ description = "fr13.inc" },
      fr2={ description = "fr2.inc" },
      fr3={ description = "fr3.inc" },
      fr4={ description = "fr4.inc" },
      fr5={ description = "fr5.inc" },
      fr6={ description = "fr6.inc" },
      fra={ description = "fra.inc" },
      frb={ description = "frb.inc" },
      frc={ description = "frc.inc" },
      frd={ description = "frd.inc" },
      fw={ description = "fw.inc" },
      gr={ description = "gr.inc" },
      lo={ description = "lo.inc" },
      nl={ description = "nl.inc" },
      pa0={ description = "pa0.inc" },
      pa1={ description = "pa1.inc" },
      pa2={ description = "pa2.inc" },
      pf={ description = "pf.inc" },
      ru0={ description = "ru0.inc" },
      ru1={ description = "ru1.inc" },
      ru2={ description = "ru2.inc" },
      ru3={ description = "ru3.inc" },
      ru5={ description = "ru5.inc" },
      ru6={ description = "ru6.inc" },
      ru7={ description = "ru7.inc" },
      se1={ description = "se1.inc" },
      se10={ description = "se10.inc" },
      se11={ description = "se11.inc" },
      se12={ description = "se12.inc" },
      se13={ description = "se13.inc" },
      se14={ description = "se14.inc" },
      se2={ description = "se2.inc" },
      se3={ description = "se3.inc" },
      se4={ description = "se4.inc" },
      se5={ description = "se5.inc" },
      se6={ description = "se6.inc" },
      se7={ description = "se7.inc" },
      se8={ description = "se8.inc" },
      se9={ description = "se9.inc" },
      sea={ description = "sea.inc" },
      seb={ description = "seb.inc" },
      sec={ description = "sec.inc" },
      sed={ description = "sed.inc" },
      see={ description = "see.inc" },
      sr={ description = "sr.inc" },
      ud={ description = "ud.inc" },
      ve0={ description = "ve0.inc" },
      ve1={ description = "ve1.inc" }
    }
  },
  one = {
    description = "Item 1",
    key = "X",
    children = {
      eleven = {description = "Item 11"},
      twelve = {description = "Item 12"},
    }
  },
}

results in an error in heuristics.lua, line 24, Trying to concatenate a nil value.

Hi! Thanks for the issue!
I'll investigate the first one. On the second, I can pretty much guess that the issue is with too few unique characters on the descriptions.
Impromptu.nvim tries to bind the option to the character on the description that's closer to the index finger/home row.
It doesn't however treat the cases where it doesn't have any unique character left but still needs a key.
Sorting also is still non-deterministic as it runs through the table with ipairs. That's on my todo as it influences the way keys are bound.

Thanks! Is this supposed to be fixed? I'm still seeing it.

Should've been fixed. I'll tackle it again.


[admin] (Resources) Updating feature request guidance

Updating the feature request links to point to Tech Community. @lindalu-MSFT, is this accurate guidance for our customers in the post-UserVoice world?

Docs Build status updates of commit 7e67e8f:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Issue_Template.md
:white_check_mark:Succeeded

README.md
:white_check_mark:Succeeded

docs/resources/resources-links-help.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

@lindalu-MSFT Thanks! I'll make some changes in corresponding repos. Should Office Scripts point here too?

@AlexJerabek Yes, do you think we need a separate label for office-scripts? Or is the "office-add-ins-development" label good for now?

@lindalu-MSFT I think a separate label makes sense. The two platforms are for different audiences and have different API surfaces. Is "office-scripts" a good enough label? That way, we can capture feature requests that are not only about script development, but end-user facing features like the Recorder and script sharing.


Move telemetry data type to JSON configuration file

Again, not a blocking comment but for the future could it make sense to gradually try to move this information from the .js files (that most users will not know how to modify) to the .json files (that instead act as a "configuration" file)?

Originally posted by @traversaro in https://github.com/ami-iit/yarp-openmct/pull/94#discussion_r813662794

[ ] Move Domain Object types description to a separate js user interface file.
[ ] Define new Domain Object types and improve the types mapping with the existing telemetry entries.

Move Domain Object types description to a separate js user interface file

Move the Domain Object types description from the dictionary-plugin.js to the const DOMAIN_OBJECTS_TYPES in the new user interface file openmctStaticServer/domainObjTypes.js.
Add a new field to the Domain Object type defintion, reportSchedule, listing all the supported modes of telemetry scheduling:

ReportSchedule.Historical: Supports historical data request (provider.supportsRequest() returns true).
ReportSchedule.Realtime: Supports periodic telemetry data streaming (realtime) to subscribers (provider.supportsSubscribe() returns true).
This field is used only on the end user interface, not on the OpenMCT API (openmct.objects.addProvider(...)).

Example of a Domain Object Type definition in openmctStaticServer/domainObjTypes.js:
https://github.com/ami-iit/yarp-openmct/blob/299bb801c4c9efb3b24fb1c6af0acbd4cbda57dc/openmctStaticServer/domainObjTypes.js#L2-L7
The Domain Object Types are identified by the respective keys, so far yarpopenmct.sensormeas and yarpopenmct.veccollectionmap. Those keys are used to map the types to the telemetry entries in the dictionaries openmctStaticServer/dictionaryIcubTelemetry.json and openmctStaticServer/dictionaryWalkingControllerTemplate.json.
Note On Javascript Enumerations
reportSchedule is of type ReportSchedule, an equivalent definition of an enumeration type in Javascript.
We can use a POJO(Plain Old Javascript Object) or a class for defining an enumeration[1].
References:

[1] https://masteringjs.io/tutorials/fundamentals/enum
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze
[3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol

This approach has some limitations:

You can modify the enum after instantiation. For example, Direction.sideways = 'sideways'.
If val === undefined, then val === Direction.notAnEnumValue and val === Direction.Downe. So typos in enum properties can cause issues.
No guarantee that property values don't conflict. Direction.Down = 'Up' is valid.

...we can solve (1) and (3) by making the class immutable with Object.freeze()[2].
Using a class adds some overhead but is more elegant from a syntax point of view. We can use Symbol[3] primitives to set the enumeration values (class static properties).

WIP: Define new Domain Object types and improve the types mapping with the existing telemetry entries
Improve type definition following its documented purpose:

type: All objects in Open MCT have a type. Types allow you to form an ontology of knowledge and provide an abstraction for grouping, visualizing, and interpreting data.


Error

So I created a batch file that echoes a random number in a new text file.  The .EXE file however doesn't work.  Can you help?

Could you provide me the batch file you're using? Just want to have a look at the code so I can replicate the issue

Thank you for your response, I cannot send you the EXACT file because it
reveals some personal info.  I will send you a .TXT file that has the same
thing but with different variables and "echoes."
On Wed, Apr 21, 2021 at 6:34 AM Akash Makvana @.***>
wrote:

Could you provide me the batch file you're using? Just want to have a look
at the code so I can replicate the issue
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/amakvana/Bat-2-Exec/issues/1#issuecomment-823959392,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATUF36SXXINRP2DWQV6TW63TJ2S2ZANCNFSM43IB7PWA
.

@echo off
cls
echo What is your favorite color
set /p color=
echo %color%>color.txt
cls
exit

Thanks for that, as soon as I get some free time tonight I'll test and get back to you :)

Ok so I have tested this. It's one of the limitations with IEXPRESS, How IEXPRESS works, is that it copies the bat script into a folder located in "%TEMP%\IXP000.TMP\" and then executes it within that directory. Once the script is completed, the folder is then deleted by itself.
See HERE and HERE for a thorough explanation.
What you can do to resolve it is use the copy /y command at the end of your script to copy the txt file into a permanent location. So for example, you could do the following:
@echo off
cls
echo What is your favorite color
set /p "color="
echo %color%>color.txt
copy /y "color.txt" "%userprofile%\desktop\color.txt"
cls
exit

Hope that helps

Awesome, thanks!
On Mon, Apr 26, 2021 at 2:44 AM Akash Makvana @.***>
wrote:

Closed #1 https://github.com/amakvana/Bat-2-Exec/issues/1.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/amakvana/Bat-2-Exec/issues/1#event-4642715928, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ATUF36SXYHUBJA2WVH6K7S3TKUDWRANCNFSM43IB7PWA
.


koordlet: fix panic during collect GPU usage

Ⅰ. Describe what this PR does
fix #904 #1062

Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews
V. Checklist

[x] I have written necessary docs and comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in make test

/lgtm
/approve

/area koordlet


Added missing indexes for SQL Server.

SQL Server does not automatically create indexes when using foreign key constraints. This PR adds them.

Still relevant.

Thanks 0x7d7b .
Note (to team) before merging and closing (and forgetting about) this PR: We'll probably want this to go into other branches (e.g. 2.3.x) as well.

I think the fields are now indexed twice. There are already clustered indexes forming the primary key:
ALTER TABLE [dbo].[QRTZ_CRON_TRIGGERS] WITH NOCHECK ADD
  CONSTRAINT [PK_QRTZ_CRON_TRIGGERS] PRIMARY KEY  CLUSTERED
  (
    [SCHED_NAME],
    [TRIGGER_NAME],
    [TRIGGER_GROUP]
  )  ON [PRIMARY]
GO

These extra indexes would make sense if there would be some generated primary key I guess.


improve middleware tests

Pull Request type
Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Does this introduce a breaking change?

[ ] Yes
[ ] No

Other information

This change is

Current dependencies on/for this PR:

main

PR #892   👈

This comment was auto-generated by Graphite.


Move court-data-adaptor from lib to app/services folder

Move court-data-adaptor from lib to app/service folder
This is a concept. I was wondering if it's worth doing this. It leads to 153 deletions and 41 additions. Also, removes that folder with a bunch of requires in it. It makes it easier to understand the code as a new guy (for me at least).
Ticket
board ticket description < should i make one of this?
Why

This is because the rails autoloader, zeitwerk, has autoloading capabilities from one of its autoload paths e.g. app/service/
https://guides.rubyonrails.org/autoloading_and_reloading_constants.html

This means no need for a bunch of require/require_relative calls.

Another benefit is not needing to require a new court-data-adaptor file every time

Also, not needing to restart the server whenever a code change is made to the court-adaptor work

How

TODO (wip)

[ ] item 1
[X] item 2

@Obsiye this was put in the lib folder as it is more of a re-usable library than a service.
As a lib it was intended that it could be shared with other apps by moving out to a gem. If you are just wanting to avoid the need to require (and restart server when changes are made) then you can look at autoloading options


feat(ECS): enable selection of listener rules

What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes https://github.com/pipe-cd/pipecd/issues/4530
Does this PR introduce a user-facing change?:

How are users affected by this change:

apiVersion: pipecd.dev/v1beta1
kind: ECSApp
input:
  taskDefinitionFile: taskdef.yaml
  serviceDefinitionFile: servicedef.yaml
  targetGroups:
    primary:
    canary:
  listenerRules:
    rules:
      - rule1
      - rule2

Is this breaking change: no
How to migrate (if breaking change):

@kentakozuka @khanhtc1202
The CI has failed due to codecov/patch.
The coverage drop is due to missing test files. Adding tests might be beyond this PR's scope.
How should we address this?
Best regards,

@moko-poi Don't worry about that. We can approve and ignore that 👌

@moko-poi Thanks so much for your contribution 🙏 There are 2 points that concern me in this current implementation.
First, not sure why we need to nest the configuration as listernerRules.rules, listernerRules directly contains rules make more sense to me.
apiVersion: pipecd.dev/v1beta1
kind: ECSApp
input:
  taskDefinitionFile: taskdef.yaml
  serviceDefinitionFile: servicedef.yaml
  targetGroups:
    primary:
    canary:
  listenerRules:
      - rule1
      - rule2

Second, as far as I understand, the current implementation (ref: code), piped can perform routing via

Updating rule (which forwarding canary/primary target group)
Updating listener (currently, clear all rules of the listener and only forwarding rule remained)

We currently don't have any way to validate the rules (set by users) is the rules which should be used to perform routing or not. That could lead to unexpected behavior if users miss setting the wrong rules to be used. Across the issue requirement, how about to keep finding current listeners of the given primary workload, then describe the listeners and find the forwarding rule to update, other rules will be remained and be included in the ModifyListener input?
We can use this API to describe specified listeners: https://docs.aws.amazon.com/cli/latest/reference/elbv2/describe-listeners.html

@khanhtc1202
Thank you for the feedback! I truly appreciate your insights.
Regarding the nesting of listenerRules.rules:You're absolutely right; having listenerRules directly contain the rules seems more intuitive.
I have now made the necessary modifications based on your suggestions. Please take a look at the updated implementation and let me know if there are any further changes or adjustments needed.
24adec0
In addition to the previous changes, I've also addressed the validation of provided listener rules against the existing rules. I'd appreciate it if you could review this new implementation as well. Thank you!
394adbf

@kentakozuka @khanhtc1202
Thank you for the Public MTG the other day.
Based on the feedback received, I've decided not to add a new feature but to upgrade the existing functionality.
When you have a moment, I'd appreciate it if you could review the changes.

@moko-poi Could you update the code to pass tests 👀

@khanhtc1202
I've made the necessary updates to the code. Please take a look and let me know if there are any further changes needed. Thanks for the feedback!

@kentakozuka @khanhtc1202
Closing this PR due to conflicts and delays. A new, updated PR has been created here: https://github.com/pipe-cd/pipecd/pull/4668. Please refer to the new PR for further discussion.
I apologize for any inconvenience and invite you to join the discussion on the new PR. Thank you for your understanding and collaboration.


Does fastapi support multiple factor authentication?

Hi everyone, Does fastapi support multiple factor authentication? (using google authenticator app)
I'm try to implement MFA into my project (my project base on full-stack-fastapi-postgresql).
Thank!

Have you considered handling MFA on the front-end?
IMHO it would be more elegant (though may not fit your use case).

Of course it does but its up to you to implement it. check out https://pypi.org/project/onetimepass/

Yep, it's something that you can implement with FastAPI indeed, but you would probably implement it on your own depending on your use case, authentication provider, how you manage users, etc.

Sorry for the long delay! 🙈  I wanted to personally address each issue/PR and they piled up through time, but now I'm checking each one in order.


Factor out ImageSlice and ImageView from Image

Description
Factor out two classes from Image in preparation for async loading for #1320.
Type of change

[x] Refactoring - no functional changes

Explanation
Image is complicated and with async and async-multiscale it's going to get way more complicated. We need to start factoring out things that will need to change or grow.
Here we factor out two new classes ImageSlice and ImageView. Together they let us organize the 4 related images that Image stores, and makes it much harder to get into a broken state. Most importantly it gives us classes that can grow particularly ImageSlice.
The new classes might look like overkill to some people, but if you focus on the diff of Image.py it cleans up things a lot. I think we'll need to a lot more like this to prepare for growth.

Before
After

_data
_data

_data_view
_slice.image.view

_data_raw
_slice.image.raw

_data_thumbnail
_slice.thumbnail.view

N/A
_slice.thumbnail.raw

Problems before:

Image class is messy, too much inline.
The 4 _data values are confusingly named

_data_raw is not the raw version of _data!
Not clear which are the raw + view pairs

i.e. that _data_thumbnail is like _data_view, both are viewable and not raw.

The per-slice attributes are not grouped or distinguished enough from _data.

Nothing enforces view will get updated when raw is updated.
No where to put new Slice specific functionality.

Before set image and thumbnail raw:
    self._data_raw = np.clip(image, 0, 1)
    self._data_view = self._raw_to_displayed(self._data_raw)
    self._data_thumbnail = self._raw_to_displayed(
        np.clip(thumbnail_source, 0, 1)
    )

After:
    self._slice.image.raw = np.clip(image, 0, 1)
    self._slice.thumbnail.raw = np.clip(thumbnail_source, 0, 1)

Context and Comments
Pylint by default restricts you to at most 7 attributes per class. 7 is not random it's the magical number.  The object becomes harder to understand, reason about, extend, test and debug. Image today has more than 70 attributes, public and private. You can see them in the debugger. A lot are through inheritance. 70 is way too many to understand or reason about.
People think 7 is impossibly low but it's not that hard. When you add your 8th attribute you look at the those 8 and say is this really a list of 8 totally unrelated attributes? Is there really no connection between any of them? No pattern, no grouping? Or can you identify 2 or more than in fact do have some meaningful connection? If so combine those attributes into something new, a named tuple, dataclass, class, even a dict.
This sounds somewhat pointless at first, didn't you just move the attribute? How is that better? The benefit accrues over time because now there is a place to put functionality that deals with only those related attributes. Functionality that doesn't clutter the base object. Functionality that only has access to the small number of related attributes in its own class.
This new object then grows and then also splits, and so on recursively. The original object is now a tree of well factored objects with focused purposes. Each one taken alone is far easier understand, reason about, extend, test and debug than original kitchen-sink spaghetti object. Not to mention each one is potentially resable in ways the original class wasn't.
7 seems like a small number but consider if you only have 3 levels of hierarchy (a.b.c) then 7 gives you ~400 attributes (7 + 7^2 + 7^3). So your 3-level object could have much more state than Image yet no single object has more then 7 attributes.
Some suggestions:

Prefer small objects, a hard or soft limit of 7 attributes.
Group attributes that are related: named similarly, updated together, derived from each other, etc.
Prefer composition to inheritance, almost always.
Prefer inheritance from small base classes, not big ones. Rather than inherit from Image have Image hold objects which have tiny inheritance hierarchies of their own.
Prefer shallow inheritance hierarchies to deep ones.

Every rule and guideline can be broken in some cases if there's some strong reason to make an exception. However in general you need to constantly be pushing on these rules because code will constantly be growing in ways that violate them. This is almost entirely a problem related to growth over time. No one sits down and types up a class that has 50 attributes. They are added 1, 2 or 3 at a time by different people over a period of years. It's almost always easier to add attributes than to thoughtfully refactor things. Just like it's easier to throw something into the garage than to re-organize what's already there. And what can it hurt going from 17 to 18 attributes? What's one more?
How has this been tested?

[x] all tests pass with my change

Final checklist:

[x] My PR is the minimum possible work for the desired functionality
[x] I have commented my code, particularly in hard-to-understand areas

I like the idea of pulling out the ImageSlice as it's own thing. I have a couple questions, just to help me see where this might be going in the future, but makes sense. It also only affects our private attributes and is fully backwards compatible for our public API.

Ultimately where do you see methods like _set_view_slice living? A method like that could take in the full nD image data and the "slicing" information and then generate an ImageSlice? In a world where we are imagining an Image Controller (as in #1325) is that something that a controller would do? Or is it an update method on ImageSlice?

Where do you see _update_thumbnail living? Now that could live in ImageSlice (I can probably figure out how to remove that dims call, all the info should be inside the ImageSlice (only ambiguity is if slice is a 3D image or an rgb image). It could also live in more "controller-like" parts of the code too after #1325.

Maybe more of a comment, the raw vs view is also a little bit unfortunate. We don't need it for the image layer, but we need it for labels right now, and even more so after #1339, but ideally we wouldn't need it at all if we fixed some things on the vispy end. It's really very much just a preprocessing of the data before sending to GPU, but unfortunately we also sort of need it for thumbnail generation, so it lives where it lives. I guess it makes sense now to add the extra class, but it would be great to be able to remove it in the future.
Right now we have two failing tests, one in test_swappable_dims because we reference _data_raw which as a short term fix could just be renamed, but we also might want to consider other options. Not quite clear to me why the labels test fails, but I can poke around. Labels subclasses Image, so maybe not surprising things we affected there too.

Maybe one further comment though on

Image is complicated and with async and async-multiscale it's going to get way more complicated.

Agreed with async-multiscale, but for async in general I was imagining affecting more of the base layer and the _set_view_slice calls and the location of the np.asarray calls as we want async to work for all our layer types. i.e. I wouldn't have thought this changes would really be required for #1320 (not that they aren't good changes though!) and maybe it does make sense to think about async for Images first

raw vs view is also a little bit unfortunate.

I didn't look very closely at labels, it's broken right now. It defines _raw_to_displayed but that doesn't exist in theImage anymore. I can put it back and yet still pass it down to ImageView to do the conversion. I'll have to fix that. I can think about the other questions once that's fixed.

affecting more of the base layer

I haven't design it all, but I wasn't picture any changes to base for a long time. #1320, #845 and #1300 are all just images. For along time the ChunkLoader will only work for Image. That's how Talley's prototype had it. What did you picture was going to happen in the base layer?

I added a "Context and Comments" section about with some observations related this reactoring. Basically lessons learned from other OO codebases.

What did you picture was going to happen in the base layer? After all three of those issues are fixed, octree is totally done, then I think we start thinking about other layers.

I guess I meant that something like the thread_worker call in @tlambert03 example would actually happen in the base layer in some generic refresh / set_view_slice method and then each layer would be responsible for defining it's own _set_data and _get_data methods that would then get executed appropriately.
Definitely best to just implement for one part of the Image layer first though, and then gradually expand the refactor to the other layers, so fine to continue on the trend, but ultimately I think we want to end in a place where we are reusing as much of the asyn machinery across all our layer types, no?

I added a "Context and Comments" section to the main PR description with some observations related to this refactoring. My experience with big complex OO codebases.

Looking now.

Some suggestions:
Prefer small objects, a hard or soft limit of 7 attributes.
Group attributes that are related: named similarly, updated together, derived from each other, etc.
Prefer composition to inheritance, almost always.
Prefer inheritance from small base classes, not big ones. Rather than inherit from Image have > > Image hold objects which have tiny inheritance hierarchies of their own.
Prefer shallow inheritance hierarchies to deep ones.

I find this very compelling, along with other points about how we got to where we are now with organic growth. I think there is a unique opportunity now to refactor napari to put us on a path towards a more maintainable codebase, we have quite a lot of stuff in there right now, a lot of eyeballs on the project, looking at many different parts of this (think event handler, MVC, world coordinates, layer groups), and it's not too late to clean things up. I think we should do this slowly, but I worry that if we don't do this now the project will suffer a year from now.
One concrete question is how do you think about "methods" on objects as opposed to "attributes", are they used interchangeably in this context? i.e. does the "rule of 7" also extend to all our functions, such as _set_view_slice or is it really just about properties like data etc?
Maybe @royerloic and @tlambert03 want to read through these comments and respond too. Ultimately if we do decide to codify these design principles, as always, I'd love to turn them into a stand alone doc we can point developers towards :-) But really great job laying these principles out @pwinston I'm learning so much from reading them.
I will make a separate comments as I review the actual PR.

Quick point, I will come back to the others later, but I've never heard anyone have an issue with too many methods in a class. I think ndarray as around 50. That's not a problem, those are just all sorts of useful things you can do with the same bits of data.

Closed by mistake!
The problem with attributes is the more there are, the more possible states the object can be in. And this rises very quickly. With 5 boolean variables the object can be in one of 32 states, with 7 it's 128 states.
Suppose you have an object and it has booleans _is_visible, _is_frozen and _is_saved or something. You can picture in each method there will be if statements "if visible and frozen but not saved" then do this. Even with 3 booleans that's getting complicated.
So the FP people say "no mutable state" and that is best. An object that simply doesn't change after construction is super easy to think about it. But with OO most people allow some mutable state. But just don't allow too much. Much more than 7 and you go off a cliff. Certainly about 10 or 15 it just gets nuts.
In effect you are not doing OO.
Objects and their relationships are the bones and the skeleton and the attributes are the meat. Generally someone at the start of the project creates the obvious domain objects, like in a game you create Player and Enemy and Level. But if you're not careful they become kitchen-sinks. You need to keep adding bones as you go, all the time. But these are less obvious, they are not domain objects, they are made-up things based on the implementation.

Going back to @sofroniewn's question "where do you see methods like _set_view_slice living?" Certainly _set_view_slice logic doesn't belong in Image itself, but I think you need to resolve #1325 to say here it should really go. #1325 is a huge question mark as to how things will ultimately look.
But if you factor _set_view_slice code into a helper that Image holds (whether ImageSlice or some new Slicer thing) you at least have it split out once you decide where you want to move it. Same with "Where do you see _update_thumbnail living", it should clearly be factored out of Image somehow, but then it depends on #1325 where it ultimately goes.
With this PR I'm trying to do the least I need to for #1320 and not just clean up Image for its own sake. But between #1320, #1300, and #845 I will probably need to keep making some changes to Image. Rendering just can't be bolted on, it's pretty invasive addition.
I don't have a good handle on #1325 but I think a lot is related to establishing the major layers in the system. I think what people are saying is they want napari's API to be as high as possible. I think this is kind of an API-first attitude which is unusual for a lot of GUI programs.

re: where should _set_view_slice live, I always found this part of the API pretty confusing depending on too much mutable state (looking at you, dims...).
Part of the problem is that historically set_view_slice is doing way too much work with the data -- is the data rgb?, is it a pyramid?, etc. Instead of this logic living in the layer code, it makes way more sense to push this logic into an object that manages access to the data. E.g.:
class DataSource:
  def __init__(self, data: array-like, space: object that describes the embedding of data in a physical space):
   self.data = data
   self.space = space

   # use self.space to figure out how to resample self.data at coords
   # this is different for different types of data -- pyramid vs rgb vs labels
   def sample(self, coords: some representation of positions in physical space): Future[array-like]
         ...
        return fut: Future[array-like]

# now in the image layer code:
class Image:
...
# this can be the same for all layers!
    self.view_slice = await self.datasource.sample(coords: some representation of positions in physical space)
...

I feel like a lot of the bloat in the Image layer is representative of missing abstractions that hopefully gets solved by world coordinates. What is data (abstractly)? Abstractly, data is a collection of values in some space, not a numpy array. What does it mean to scroll through data (abstractly)? Scrolling through data is resampling the data at sequence of planes in space, not array indexing.
I think it would be best if the layer has absolutely no clue how spatial coordinates, or some sparse representation of coordinates (like a definition of the angle + offset of a plane) are turned into displayable intensities. The layer knows how to ask its data "what are your intensities $here?" and then it is responsible for preparing those intensities for display.

@d-v-b that's moving things in a useful direction. Although I think #1325 is saying that Image can't have a self.view_sice like you are showing. For multiple reasons but one is there could be N views of same data (e.g. XY, XZ, YZ). Really that's the open question, is Image the data being viewed or is it a view of the data? And not just Image it's all our layers. What are layers? Are they data or are they views of that data? I think #1325 is trying to resolve that?

Although I think #1325 is saying that Image can't have a self.view_sice like you are showing. For multiple reasons but one is there could be N views of same data (e.g. XY, XZ, YZ).

Right, that's a good point. So I'm not sure where set_view_slice should live, or what could take its place on the layer side...

What are layers?

Yeah, this is a great question! I would love to see a high-level justification / explanation of what layers are, and how they relate to to the underlying image data.

I think a general pitfall when writing GUI apps is creating an object model that's based too closely on your "user interface objects". You can point to "a layer" on the screen, it's that little rectangle with eyeball on it, so surely there's a class which implements everything that rectangle does?
I think for any GUI program that's any easy path to get suckered down. But it's particularly problematic if you want a versatile and powerful API, because almost by definition the users of your API are not constructing a GUI that looks exactly like your GUI. They are not constructing a GUI at all, or they are making a very different GUI.
They don't want to construct their thing out of your user interface objects, they want to construct out of some more general set of objects. Your GUI is the marquee example of what you can with those objects, but that's like the LEGO model on the box, it's just one thing you can build.
It's a balancing act though because it's super easy to get bogged down making stuff too general. This is the idea of YAGNI it says focus on what you need today, the rest can wait. But I think making an API is kind of special case, you do need to look ahead to what people are going to build with that API, and you do need to acknowledge it won't be exactly what you built.

There was universal enthusiasm for this PR in team meeting today, @royerloic and @0x00b1 both said they love the direction.
As the PR is fully backwards compatible and only affects private objects I'd like to merge tomorrow. That will let @pwinston make https://github.com/pwinston/napari/pull/4 directly against the repo and will let me incorporate these changes into a new version of #1276 world coordinates which includes these design principles. If @jni has requests changes they can easily be included in a standalone PR or in the upcoming chunk loader PR.

  I really like the discussion above. But @sofroniewn's final comment alarmed me enough to pull me from my idyllic slumber. =P
I agree with the general principles in the discussion, but in general I despise codebases with lots and lots of new objects. I think the 7 attribute rule is excellent, I'd love to see us stick to that. But having a three-level deep hierarchy of newly defined objects also alarms me, and in some sense is pushing the global state underground, rather than getting rid of it. What does get rid of global state is implementing as much as possible as functions with simple inputs (simple = standard, well-known objects) and simple outputs.

I think ndarray has around 50 methods. That's not a problem, those are just all sorts of useful things you can do with the same bits of data.

I think you'll find that the NumPy devs disagree and think that they added too many methods that should have been functions. So I actually would like to see us aim to reduce the number of methods and implement as many of those as external functions that operate on attributes and return useful values with which to update those or other attributes.
The main reason I wanted to chime in here though, which shouldn't actually need to hold up this PR I don't think, is this paragraph:

In my mind the main thing for #1320 (async non-multiscale images) is something in Image which holds the slice image data but it can be in 3 states: Empty, Waiting, and Done. So it's Empty to start, default blank image, then you decide the data is needed you request it from the ChunkLoader and you are Waiting, then when the data is finally there it's Done and you can draw it.

Sure, but (a) this something should eventually be something in base, not image, since all the other layers also get sliced, and (b) you're actually describing a Python concurrent.Future: https://docs.python.org/3/library/concurrent.futures.html (well, optionally a None, to represent Empty). So, regardless of whether we use an ImageSlice object in the end, I think we should probably use this standard API to represent async data, rather than build our own from scratch. But the caveat is that I don't know whether it's easy to make this gel with Qt. But I just wanted to make sure that you're aware of that API, which dask distributed also uses btw.

Hearty +1 on using futures

this something should eventually be something in base, not image

It will eventually be in base, yes. Right now it's in Image because #1320, #845 and #1300 all only deal with Image, and I'm focusing on those issues.
But yeah that's why it's called ChunkLoader and not ImageLoader, a "chunk" is a deliberately vague term that eventually will include geometry, etc. A chunk is meant to be "the data backing an independently loadable and renderable subset of what you are trying to draw".

you're actually describing a Python concurrent.Future

The WIP async PR used concurrent futures from the first commit, they are super easy to deal with:
https://github.com/pwinston/napari/pull/4
However right now it keeps the futures internal to the ChunkLoader and does not pass futures back to the image layer. I think this is the right design but it would take some discussion to explain. Once I open a PR on that change we can get into it. That new PR is at least 10x maybe 100x bigger than this one in long term impact, so definitely something we'll need to scrutinize.

As noted above I am going to merge now, all doc string comments were addressed apart from the use of custom types, but I think that warrants its own larger conversation and is something we can come back to

But having a three-level deep hierarchy of newly defined objects also alarms me

My calculation that "3 levels of hierarchy gets you 400 attributes" was not at all meant to advocate we create object hierarchies with 400 attributes. I'm just saying when you raise 7 to a power, it gets big fast. I don't think even Image's 70 attributes should turned into one big object hierarchy. I think Image should be split like in #1325 then those smaller objects decomposed.
To summarize my position:

Mega objects: bad
Mega object hierarchy: better, but still bad
Reasonable size objects, good.

What does get rid of global state is implementing as much as possible as functions with simple inputs (simple = standard, well-known objects) and simple outputs.

This works well in some languages, but isn't it really hard with Python because there is no const? If you have a function def calc_new_thing(old_thing): what prevents the function from modifying old_thing with public methods or public attributes? What enforces immutability? Let me guess, a docstring?
That said, I'm all for simple/pure functions. They are great. I see no downside to adding good simple functions to a codebase. If done well their "conceptual weight" is zero, if they do their job and work they are all upside. As long as their implementations are reasonable: a nice pure function which inside is a huge messy imperative program is not good.
I do think people that have done a lot of math/numerical code don't realize what a huge special case that type of code is. I think creating simple functions for math related code is like 10,000X easier doing it in some other places. A lot of math simply is a bunch of functions, so yes a lot of time that's the best way to implement them.
A definitely think a good OO codebase is a mix of simple functions and objects, OO does not mean "everything has to be an object" to me at all.

This works well in some languages, but isn't it really hard with Python because there is no const? If you have a function def calc_new_thing(old_thing): what prevents the function from modifying old_thing with public methods or public attributes? What enforces immutability? A docstring?

Convention, which is the way most things work in Python. In scikit-image, we work with the implicit assumption that input variables are only modified if in_place=True is passed, or out=arr and arr is also the input array. I think this works totally fine.

However right now it keeps the futures internal to the ChunkLoader and does not pass futures back to the image layer. I think this is the right design but it would take some discussion to explain. Once I open a PR on that change we can get into it. That new PR is at least 10x maybe 100x bigger than this one in long term impact, so definitely something we'll need to scrutinize.

Sure, we can postpone that discussion, but expect some gentle resistance from me. =P My preferred design is for what we now call data_slice to be not an np.array but a concurrent.Future whose result is a np.array. We can then have a ChunkLoader or whatever externally manage the computation of those futures.
But, as you say, this is probably something best left to discussion on the PR itself.


Remove npm-shrinkwrap.json

Would you consider removing npm-shrinkwrap.json from the published ganache-core package? The use of shrinkwrap in this library makes it painful to use for two main reasons: it dramatically increases the number of dependencies we need, and it makes updates to transitive dependencies (to address bugs or security advisories) difficult.
To quote the npm docs on npm-shrinkwrap.json:

The recommended use-case for npm-shrinkwrap.json is applications deployed through the publishing process on the registry: for example, daemons and command-line tools intended as global installs or devDependencies. It's strongly discouraged for library authors to publish this file, since that would prevent end users from having control over transitive dependency updates.

If there are specific packages that need to be pinned, that can be done via package.json. But using shrinkwrap is counter-productive, and a constant source of friction. It's reasonable to use a shrinkwrap for ganache-cli, but I don't see the case here.
Possible Solution
Rename npm-shrinkwrap.json to package-lock.json, and explicitly pin any dependencies that must be a specific version for this library to function correctly. Use at least a ~ range for others (if not a ^ range), to ensure projects that use this dependency are able to easily update these dependencies when necessary.

I see; so you're less concerned about legal liability, and more concerned with preventing event-stream-like attacks and the negative fallout on your team that might follow. Sure, that makes sense.
I concede that you do have a pretty good reason. There is still a case to be made for removing it though:

Using shrinkwrap for this purpose is not commonplace; there is no social expectation of libraries taking steps to prevent malicious packages from making their way into a project. No reasonable person could possibly blame your team if something like that happened.

Projects must be responsible for their own dependencies, including transitive dependencies. At best, your team could prevent malicious packages from being brought into a project via ganache, but of course that's not enough. Projects must also ensure non-ganache dependencies aren't malicious. Any responsible project must already be taking steps to prevent this, either by waiting a while before making non-essential updates (as you do), or auditing each one, or some combination of those strategies. If not, they're not safe.
Moreover, you're not even necessarily making this task easier on projects, as you're increasing the number of packages that need to be checked (unless they're willing to wholly trust your team, which might not be justified for an outsider that doesn't know how your team operates, and hasn't established trust). In practice most projects don't even strive to be this diligent, so you're clearly reducing the chances of a malicious package attack in most cases by shipping a shrinkwrap file. But among the small number of projects who are similarly diligent, you may be making their task more difficult.

Using a shrinkwrap file can prevent projects from updating packages to address security vulnerabilities. Your team do do a fairly good job of keeping up on these, and I appreciate the standing offer to submit PRs to address them, but I can't take advantage of that without updating ganache as well. That's not always an option. Right now for example, I'm using an older version of ganache and my tests break when I update (possibly due to a bug in ganache, but more likely we're relying on a bug that you fixed). So I'm forced to decide between investing a great deal of time and effort now in updating ganache, leaving the security advisory unaddressed, or pursing some workaround. I'd rather that I wasn't put in that position.

This approach of using a shrinkwrap file to slow down updates, as a means of preventing event-stream-like attacks, sets a bad precedent, and it would be bad if the rest of the community followed suit (i.e. it fails the categorical imperative :sweat_smile: ). On the one hand it is admirable that you care about this problem, and that you've gone to such lengths to solve it, but on the other hand it's ultimately bad for the ecosystem of project maintainers have less control over their dependencies. This is especially true of library maintainers that are less diligent than you in reacting to vulnerabilities like that ENS one. Even if you can make it work, it's the wrong way for the ecosystem as a whole to tackle this problem.

The workarounds are imperfect. The --no-shrinkwrap flag for example seems to not update the lockfile at all when I use it? (possibly just a bug with npm - not entirely sure how this is supposed to work though). No such flag exists with yarn. yarn does have another workaround (yarn resolutions), but it would be extremely tedious to use resolutions to change each dependency of a large project like this. Ultimately most projects won't use a workaround for one reason or another, meaning they'll be affected by problems I mentioned earlier of increased number of dependencies and outdated dependencies.

Using shrinkwrap is more work for you and your team.

None of this invalidates the reason you outlined for using shrinkwrap; you have a good reason and I won't dispute that. But there are substantial downsides. I can't say for sure what I'd do in your place, but I suspect that I'd be inclined to remove it. Either way, thanks for hearing me out.

Closing for issue maintenance. Thanks for your thoughts!


[app] Configure attribute to access the user's name

Closing this issue, because it's already implemented by AADAuthenticationProperties#userNameAttribute


Exception error when trying to export/download a plan

https://dmptool-dev.cdlib.org/plans/1265/download - this isn't occurring in stage

When I try to export a plan I receive an error
ActiveRecord::RecordNotUnique in PlansController#export
Mysql2::Error: Duplicate entry 'ExportedPlan-265-export' for key 'index_settings_on_target_type_and_target_id_and_var': INSERT INTO settings (value, var, target_type, target_id, created_at, updated_at) VALUES ('---\nformatting:\n :margin:\n :top: 25\n :bottom: 20\n :left: 12\n :right: 12\n :font_face: Arial, Helvetica, Sans-Serif\n :font_size: 10\nmax_pages: 3\nfields:\n :admin:\n - project_name\n - project_identifier\n - grant_title\n - principal_investigator\n - project_data_contact\n - project_description\n - funder\n - institution\n - orcid\n :questions: :all\ntitle: ''\n', 'export', 'ExportedPlan', 265, '2018-02-23 16:19:54', '2018-02-23 16:19:54')

@bhavi - I can download most of my plans on dev and stage. So far two that caused (different) errors on dmptool-dev are:

DMP Template from DCC - I just received a "Bad Gateway" message for all file formats
USGS DMP Guidance template

1 - Details for plans that threw errors (first and last plan in list)

2 - No Method error for USGS DMP Template

https://dmptool-dev.cdlib.org/plans/1265/download - this is no longer causing an error in dev.

for the USGS template I get the same No Method error for text format only. All other file formats work.
for the DMP Template from

This should be ok now. I'm not able to replicate the Bad Gateway error. I think it may just be a glitch with the dev data. I've tested several plans based on the DCC template in stage with no issues

yes the USGS is fixed! i won't worry about the other one since it's difficult to distinguish bad data from bugs at this point.

Bad Gateway usually happens when the server is unable to respond to the request. I think the DCC one may even have been a situation where you tried to access it while the site was being restarted. Did it happen multiple times or just once? We can verify this afternoon once the migration has been run on stage.

i've tested it about 10 times now over a few days and it happens every time. will test again post migration.


[NP-3464] FileSelect_v1

add SessionWebAgent back

Ok, understand why spid is an issue.
Do the following:
Add a Relationship with User, so a user had 'files' and a file has an 'owner'.
Permissions will be needed for the fraud, paymentops groups to read    file.read.*  sort of thing.
Then file in auth on read can be:  file.read.id  and the owner, system/admin, and fraud ops can read.
auth on read will not do the auth check if the file.owner is null.
If the file is reference when not logged in, then only files without an owner can be read. So we can use these for all the terms and conditions and other global or pre-login stuff.
and the owner can be any type of user - (contact, business). ...

add Owner check to fileService
remove async from data getter
fix getText method
update filePreview to show text


Updated db initailization failed message to be more descriptive

I'm not really sure you're guys convention for error handling so I figured I'd just throw this out there, spent about 10 minutes figuring out that my DB was not configured correctly. "initialization failed" is a very generic error message to return to the top-level, but "database initialization failed" would at least give me a better idea of where to start looking. Plus, all other instance of KingPhisherDatabaseError appeared to give some indication it was DB related in the message.

This looks great thanks @jacobj10! I'll get it landed shortly.


AOT error on reflection with il2cpp build

I'm sorry I'm not good at English.
An error occurs when starting the actual machine under the following conditions.
1.Unity version 2017.
2.Call a function that requires a parameter by reflection.　(Observable Class Zip)
3.Use generics for parameters when calling reflection.

revised part

https://github.com/neuecc/UniRx/blob/master/Assets/Plugins/UniRx/Scripts/System/Tuple.cs#L138
public struct Tuple → public class Tuple

https://github.com/neuecc/UniRx/blob/master/Assets/Plugins/UniRx/Scripts/System/Tuple.cs#L209
public struct Tuple<T1, T2> → public class Tuple<T1, T2>

https://github.com/neuecc/UniRx/blob/master/Assets/Plugins/UniRx/Scripts/System/Tuple.cs#L304
public struct Tuple<T1, T2, T3> → public class Tuple<T1, T2, T3>

https://github.com/neuecc/UniRx/blob/master/Assets/Plugins/UniRx/Scripts/System/Tuple.cs#L414
public struct Tuple<T1, T2, T3, T4> → public class Tuple<T1, T2, T3, T4>

https://github.com/neuecc/UniRx/blob/master/Assets/Plugins/UniRx/Scripts/System/Tuple.cs#L541
public struct Tuple<T1, T2, T3, T4, T5> → public class Tuple<T1, T2, T3, T4, T5>

https://github.com/neuecc/UniRx/blob/master/Assets/Plugins/UniRx/Scripts/System/Tuple.cs#L683
public struct Tuple<T1, T2, T3, T4, T5, T6> → public class Tuple<T1, T2, T3, T4, T5, T6>

https://github.com/neuecc/UniRx/blob/master/Assets/Plugins/UniRx/Scripts/System/Tuple.cs#L842
public struct Tuple<T1, T2, T3, T4, T5, T6, T7> → public class Tuple<T1, T2, T3, T4, T5, T6, T7>

Can you provide more details, what error did you encounter exactly? Can you show some sample code that triggers the issue? I want to make sure my project is not affected :)


feat(table): add overflow menu to row actions with isOverflow

Summary

Add the isOverflow prop to add an Row Action to each Row's overflow menu.

Change List (commits, features, bugs, etc)

This PR can't be reviewed until the previous PR comes in as it depends on the Table refactor

Related Issues

Closes IBM/carbon-addons-iot-react#22

Acceptance Test (how to verify the PR)

Check the Row Expansion with Actions story and the Stateful Table story

pushing a few adjustments shortly

Flipped the menu

:tada: This PR is included in version 1.14.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.14.0 :tada:
The release is available on npm package (@release-1.x dist-tag)
Your semantic-release bot :package::rocket:


Error: Response has status code 0

When we load in the font picker were seeing a Error: Response has status code 0. It looks like the Google Font request is failing as well.

The problem seems to be API failed while fetching the style for Roboto. Remove the font family while creating the text object.


Multiball and Multiball Lock

Currently, multiball and multiball_lock are only loosely coupled. Change that so that:

Multiball will decrease lock count when requesting a ball from the lock
Multiball cannot reference a ball_hold by accident
Source device should still be possible to configure (by default the source device of the playfield). They will be used if the lock does not have enough balls

Hi @jabdoa2, has this been implemented yet? If not, I would love to take a look at it.


k8ssandra webhook cert process will not work with cass-operator 1.8.0

Bug Report
Describe the bug
Since we changed the Secret TLS-cert handling in the cass-operator's master version, the current functionality of just deploying a secret will not work. It will not be loaded by the cass-operator, but instead needs something else that will mount the secret correctly.
Expected behavior
User enabling the webhooks should have them.
┆Issue is synchronized with this Jira Bug by Unito

@jdonenine This is actually k8ssandra helm charts related issue. Not sure which repo is the correct place.

Is this a k8ssandra chart issue? We don't deploy the webhook in k8ssandra.


Missing the strong tag in reset.css

Hello Leonardo and beer fellaz,
I'm having an issue because of my markdown rendering.

This text is bottom aligned

This text is NOT bottom aligned

Can you add the strong tag here ?
https://github.com/beercss/beercss/blob/8a6ce3e35de6965decd3c51c6b7c23ea58d5ffc4/src/cdn/helpers/reset.css#L26C7-L26C7
Thanks

I agree

Done in v3.4.10 (https://github.com/beercss/beercss/releases/tag/v3.4.10)


inserting into w/ column names doesn't work properly

Describe the bug
There are two problems right now on 0.1.14-rc:

The RisingWave doesn't insert a null by default for ignored columns
The data inserted is not aligned w/ the column names

To Reproduce
On RisingWave 0.1.14-rc
dev=> create table t (v1 int, v2 int, v3 int);
CREATE_TABLE
dev=> insert into t (v1, v2, v3) values (1, 2, 3);
INSERT 0 1
dev=> insert into t (v2, v3) values (2, 3);
ERROR:  QueryError: Bind error: INSERT has more target columns than expressions
dev=> insert into t (v2, v3, v1) values (2, 3, 1);
INSERT 0 1
dev=> select * from t;
 v1 | v2 | v3
----+----+----
  1 |  2 |  3
  3 |  1 |  2
(2 rows)

Expected behavior
On PG
postgres@192:postgres> create table t (v1 int, v2 int, v3 int);
CREATE TABLE
Time: 0.048s
postgres@192:postgres> insert into t (v1, v2, v3) values (1, 2, 3);
INSERT 0 1
Time: 0.031s
postgres@192:postgres> select * from t;
+----+----+----+
| v1 | v2 | v3 |
|----+----+----|
| 1  | 2  | 3  |
+----+----+----+
SELECT 1
Time: 0.041s
postgres@192:postgres> insert into t (v2, v3, v1) values (2, 3, 1);
INSERT 0 1
Time: 0.082s
postgres@192:postgres> select * from t;
+----+----+----+
| v1 | v2 | v3 |
|----+----+----|
| 1  | 2  | 3  |
| 1  | 2  | 3  |
+----+----+----+
SELECT 2
Time: 0.089s
postgres@192:postgres> insert into t (v2, v3) values (2, 3);
INSERT 0 1
Time: 0.064s
postgres@192:postgres> select * from t;
+--------+----+----+
| v1     | v2 | v3 |
|--------+----+----|
| 1      | 2  | 3  |
| 1      | 2  | 3  |
| <null> | 2  | 3  |
+--------+----+----+
SELECT 3
Time: 0.279s

Additional context
No response

The first problem on null is an intentional intermediate step. #6128
The second problem is likely a bug of #5697 @CAJan93 Could you please take a look?

Hey @xiangjinwu, I want to have a look, but am busy with the meta HA setup at the moment. How urgent is this? Is it okay if I have a look at it in some time?

Maybe we can consider this feature as not-yet-fully-supported in 0.1.14, which includes (1) updating insert into t (v2, v3, v1) to an unimplemented error in 0.1.14-rc and (2) resolving both issues in 0.1.15. What do you think? @cyliu0

@xiangjinwu @CAJan93 Since INSERT is a very common statement in databases, really hope this could be fixed ASAP

I will work on the INSERT bug. Draft PR will be posted here: https://github.com/risingwavelabs/risingwave/pull/6590
Atm I do not have capacity for the null feature.

I believe I fixed the bug. Please have a look at the PR: https://github.com/risingwavelabs/risingwave/pull/6590

https://github.com/risingwavelabs/risingwave/pull/6590 is merged. I hope that the bug is fixed and that the column is now alligned with whatever is defined in the INSERT statement. Thank you @chenzl25 for you approval

@fuyufjh @CAJan93 Do we need to cherrypick the fix into 0.1.14?

@fuyufjh @CAJan93 Do we need to cherrypick the fix into 0.1.14?

Yes, please do it

Thank you for cherry-picking @cyliu0. Cherry-picked commit on v0.1.14-rc is 4c508c2602e025108258b180c392b514dea1f44e

Fixed in https://github.com/risingwavelabs/risingwave/pull/6590


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/101837

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/101845

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/112574

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/116313


Add more cases for ConstructCascadingConfigmap unit test

Hi community,
This issue is for #73
Aim
Add more cases for ConstructCascadingConfigmap to improve unit test coverage.
The function is https://github.com/apache/shardingsphere-on-cloud/blob/2f348ea1208b3396ddbe873a60f32369578f8697/shardingsphere-operator/pkg/reconcile/resource.go#L239
The cases should be added to https://github.com/apache/shardingsphere-on-cloud/blob/main/shardingsphere-operator/pkg/reconcile/reconcile_test.go.
Basic Qualifications

Golang Unit Test
stretchr/testify/assert
Kubernetes Deployment

This will be closed since the controllers and reconcilers have been refactored.


pod update for quickstart testing

Fix #8809
Run pod update instead of pod install for all quickstart testing. After running localize_podfiles, we should make sure that Podfile.lock contents don't prevent updates for dependencies.
Also don't be quiet so that logging can help with diagnosis.

Because GoogleUtilities 7.6.0 is currently on SpecsStaging, I updated the Firebase podspecs to require it,  and the quickstart Podfile.lock's are set to GoogleUtilities 7.5.x


Forward logs from checkout service to otel collector

Changes

Logrus log bridge used to forward go service logs to otel collector

Opened PR here by mistake rather than on the fork.

Hey @kkn would you like to contribute this to the demo?
We would love to add logs bridge to the service, and it seems you have it there.
It would just be matter of cleaning up the PR and signing de easyCLA.
WDYT!?

Hey @julianocosta89, yes, I would like to contribute.
Let me test the changes on my cluster for all the Go services and raise a PR here.

Awesome!


feat(cli): support committing "gas commit" command

Pull Request Test Coverage Report for Build 848200463

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 80.83%

Totals

Change from base Build 842941456:
0.0%

Covered Lines:
4246

Relevant Lines:
5253

💛  - Coveralls


Improved and fixed server definition file format

See commit message.

Coverage increased (+4.7%) to 73.786% when pulling b75da4cb9f69c5802cbc430eecceee21b1178af2 on andy/improve-sdf-format into af6fe6e88ddaca22b77a9260588f5d600d89566e on master.


Cross-compile for Scala 3

Updated all deps besides cassandra-driver, moved to testcontainers instead of cassandra-launcher like in here, removed pureconfig derivation and cross compiled against 3.3.3, 2.13.13 and 2.12.19.
TODO:

[ ] add https://github.com/scalacenter/sbt-version-policy

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

81 of 81 (100.0%)  changed or added relevant lines in 12 files are covered.
8 unchanged lines in 6 files lost coverage.
Overall coverage increased (+13.5%) to 90.096%

Files with Coverage Reduction
New Missed Lines
%

scassandra/src/main/scala/com/evolutiongaming/scassandra/LoadBalancingConfig.scala
1
11.11%

scassandra/src/main/scala/com/evolutiongaming/scassandra/QueryConfig.scala
1
82.35%

scassandra/src/main/scala/com/evolutiongaming/scassandra/ReconnectionConfig.scala
1
40.0%

scassandra/src/main/scala/com/evolutiongaming/scassandra/SocketConfig.scala
1
75.0%

scassandra/src/main/scala/com/evolutiongaming/scassandra/ReplicationStrategyConfig.scala
2
74.07%

scassandra/src/main/scala/com/evolutiongaming/scassandra/SpeculativeExecutionConfig.scala
2
20.0%

Totals

Change from base Build<PHONE_NUMBER>:
13.5%

Covered Lines:
655

Relevant Lines:
727

💛  - Coveralls

I did not double check if all properties are tested in unit tests. May be will do later.

@rtar, @Z1kkurat do you think we can merge it soon?

@rtar, @Z1kkurat do you think we can merge it soon?

@rtar i have no objections, let's merge?

Yes, let's do it!

I just thought: does pureconfig derive codecs that can read only dash-separated names, or does it allow dots too? In other words, is it able to read only "connect-timeout", or can it read connect.timeout too? If the latter is the case then we need to support that

@Z1kkurat I believe . would mean nesting in HOCON.
By default pureconfig maps from camelCase values in case classes to kebab-case values in config files. This can be configured by ProductHint but we weren't changing it.

One note, though. If it was not tested for binary compatibility, it might need to be released as a new major version with all the consequences involved.

there were no changes to the API though, why do you think a compatibility could be broken?

@rtar Grzegorz updated the version to 6.0.0, as you asked (though I think it was unnecessary). Shall we merge this, please, or do you have any other concerns? This PR is quite big, and I don't want to delay it for longer

I suggest to merge it. I think it is fine to release it as 5.x if binary compatibility is maintained.

@grzegorz-bielski, without going over all the files again, could you confirm only internals were changed without changes to signatures and APIs? I'd honestly prefer to keep the version to 5.x, otherwise it's going to be a lot of pain further down the road

@Z1kkurat The only change in the main API was splitting the implicit config readers to a separate trait like AuthenticationConfigImplicits, which is then mixed with original object like AuthenticationConfig. Variable names were not renamed, so the change should be backwards compatible.

I have set up the sbt-version-policy locally ( I don't know do include it in this PR to reduce the scope)
After f175a86 scassandra / mimaReportBinaryIssues doesn't report any issues but scassandra / versionPolicyCheck returns:
[error]   ch.qos.logback:logback-classic: missing dependency
[error]   ch.qos.logback:logback-core: missing dependency

Not sure why, since I didn't remove it. 🤔

I suggest to merge it, and I think we can consider it binary compatible (i.e. release it as 5.x).

@rtar Should I change the version to 5.1.0 or can we leave at 5.0.3-SNAPSHOT ?

I am not sure, but I think you should use 5.0.3-SNAPSHOT if it is source-compatible and binary-compatible, and use 5.1.0-SNAPSHOT if it is only binary-compatible.
I think you might also use 5.1.0-SNAPSHOT to show the significance of having Scala 3 support.
To summarize, it is up to you :blush:

Since it also removes the transitive logback dependency then let's go with 5.1.0-SNAPSHOT and :shipit:


Added resource to Free tools

In this pull request

[..]  I am adding a new resource.
[ ]  I am adding a new step
[ ]  I am providing an edit
[ ] Removing a resource

Adding new resource

The resource I am adding is adding another Free tool
I am adding this resource to _ _ _ _ step.
I think this resource deserves to be in this list because _ _ _ _

Do not add more than one during hacktoberfest
Add new step

The step I am adding is _ _ _ _
The reason why I think this step should be there is because _ _ _ _

[ ] I have added at least one resource to this step

Do not add more than one during hacktoberfest
Providing an Edit

The edit I am providing is to _ _ _ _

Do not add more than one during hacktoberfest
Remove a resource

The resource I am removing is _ _ _ _
I am removing this resource from _ _ _ _ step.
I think this resource should not be in this list because _ _ _ _

Don't ask to remove stuff - unless you believe the content violates the code of conduct

Great


Support for various tw_stime types

We have had several requests for supporting arbitrary tw_stime types (see #58 and #34). Could we provide an API for developers to specify their own tw_stime type? What would we need to change?

The toughest part from a modeling perspective IMO is handling the relationship between tw_stimes and RNGs. For example, floating-point random functions are used fairly extensively in models to add random noise to functions, many of which are less than 1 - tw_rand_unif, for example, returns values in the range (0.0, 1.0) (not sure whether the range is exclusive or not). We'd need to make our models aware that we may no longer be using fractional values. Similarly, we'd likely want to drop down below nanosecond granularity if using integer tw_stime, so handling units correctly would be important (more of a CODES issue than a ROSS one, but mentioning here for completeness).
A cmake option at ROSS build time for controlling the type of tw_stime would be sufficient (this is probably obvious, but wasn't sure whether you were talking about a programmatic API or a build option).

resolved by #159.
As to @JohnPJenkins 's comment: This is the responsibility of the model developers. The model developers must determine which type they are using for tw_stime and adjust accordingly. Since it's a build-time thing, there should be no impact to codes.


Add README to clarify sourcecode for community contribution

Description
As we are working to empower people on Twitter to add notes to tweets that might be misleading, it is important to have a clear understanding of what each of the 12 Python files in the sourcecode/ directory does. While the explanation of the codes is written on themselves, having a bird's eye view in layperson's terms through a README.md or README.txt would greatly help people who want to participate in a more informed world.
Proposed Changes
Add a README.md or README.txt file in the sourcecode/ directory to give an overview of the purpose of each of the 12 Python files. The README should explain in layman's terms what each file does, and how they work together to power Community Notes.
Benefits
A clearer understanding of the source code for people who are interested in participating in the project. Increased transparency and accessibility of the project, making it easier for people to contribute.
Impact
A well-written README will help the Community Notes project to grow and improve, by providing a clear and concise overview of the code that powers the project. This will make it easier for people to understand how the project works and how they can contribute to it.
Checklist

Add the README.md or README.txt file to the sourcecode/ directory.
Verify that the README.md or README.txt file accurately explains the purpose of each of the 12 Python files in layperson's terms.
Verify that the file is well-written, easy to understand, and accurately represents the project.

Additional Information:
Dear developers,
I hope this message finds you well. I wanted to bring to your attention a suggestion that could enhance the usability and accessibility of the Community Notes project. As you are the main contributors and have a deep understanding of the Python codes powering the project, I believe you would be the best suited to address this issue.
Thank you, and I look forward to your response.
Best regards,
Ralph

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

Thanks @ralphcajipe. We've turned on "Issues" for the repository, which is a more appropriate way of raising suggestions like this.
Would you mind adding this there as a new issue?
https://github.com/twitter/communitynotes/issues/new/choose

Thanks @lucasnantonio for the response. I've added now this suggestion as a new issue https://github.com/twitter/communitynotes/issues/54


Add instructions to check weave-kube logs

"Check it is running" and "check the logs" are important steps when troubleshooting.

Nice one!

Can we see those in Scope or Weave Cloud?

Yes, there is a "logs" button, but it's not a great user experience if there are a lot of lines to scroll.
More importantly if your pod network is not working it is unlikely you will have successfully installed the Weave Cloud agents.


Package URl
<EMAIL_ADDRESS>CPE
cpe:2.3:a:asp-project:asp-project:1.0:::::::*
CVE
CVE-2009-0280
ODC Integration
{"label"=>"CLI"}
ODC Version
8.2.1
Description
Using Azure DevOps pipelines with https://marketplace.visualstudio.com/items?itemName=dependency-check.dependencycheck
This version has no known vulnerabilities!
https://ossindex.sonatype.org/component/pkg:nuget/AspNetCoreRateLimit.Redis@1.0.0?utm_source=dependency-check&utm_medium=integration&utm_content=8.2.1

approved


[FR] Support License-File root license directory (PEP 639)

What's the problem this feature will solve?
The License-File core metadata tag definition in https://peps.python.org/pep-0639/ was updated. Specifically:

Root License Directory (Short: License Directory)
The directory under which license files are stored in a project/distribution
and the root directory that their paths, as recorded under the License-File
core metadata fields, are relative to. Defined here to be the project root
directory for source trees and source distributions, and a subdirectory
named licenses of the directory containing the core metadata
(i.e., the .dist-info/licenses directory) for built distributions and
installed projects.

And:

As specified by this PEP, [License-File] value is also that file’s path
relative to the root license directory in [...] installed projects [...]

Translated to human language, when the License-File looks like this:
License-File: LICENSE

The file should be located in ...dist-info/licenses/LICENSE. Currently, it is located in ...dist-info/LICENSE directly, based on a previous iteration of this PEP (which is til a draft).
Describe the solution you'd like
When including license files in dist-info, move them to the licenses directory.
Alternative Solutions
An alternate solution is that a tool that reads the License-File core metadata tag should look for the files in both locations.
Additional context
hatchling already follows this and includes the license files in the licenses directory.
Thank you :heart:
Code of Conduct

[X] I agree to follow the PSF Code of Conduct

Thank you for the ticket @hroncok.
My doubt here is if we should wait until PEP 639 is finalised instead of risking implementing it again and having to change later.
This issue also might require coordination with the wheel package.

My doubt here is if we should wait until PEP 639 is finalised instead of risking implementing it again and having to change later.

PEP 639 has been provisionally accepted (with one of the conditions being implementation in at least two build backends :pleading_face:), so this issue now describes the solution agreed upon.

Thank you very much @befeleme.
If any member of the community is interested in giving it a go, PRs are very welcome.


ConnectionError

Hello,
I get the following error when trying to use it (with the exact instructions on the README, using lidarr on a local docker):
requests.exceptions.ConnectionError: HTTPConnectionPool(host='lidarr', port=8686): Max retries exceeded with url: /api/v1/wanted/missing?page=0&pageSize=50&sortDirection=descending (Caused by NameResolutionError("<urllib3.connection.HTTPConnection object at 0x7f23f864fbb0>: Failed to resolve 'lidarr' ([Errno -2] Name or service not known)"))
If I change the host name to localhost, instead of the container name, I get:
requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=8686): Max retries exceeded with url: /api/v1/wanted/missing?page=0&pageSize=50&sortDirection=descending (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7ffbb267bbb0>: Failed to establish a new connection: [Errno 111] Connection refused'))
I can see lidarr on my browser at http://localhost:8686 and from other containers (e.g. prowlarr) at http://lidarr:8686.
Any idea how to fix it?

Solved it by adding --network={the docker network name for the lidarr container}.
For some reason it now gets stuck showing Starting Lidarr Youtube Downloader


Add: Persiana Latino

Channel Name
Persiana Latino
Alternative Names (optional)
No response
Network (optional)
Persiana
Owners (optional)
Persiana Media Group
Country
FR
Subdivision (optional)
No response
City (optional)
No response
Broadcast Area
c/IR
Languages
fas
Categories (optional)
general
NSFW
FALSE
Launched (optional)
2023-03-20
Closed (optional)
No response
Replaced By (optional)
No response
Website (optional)
https://www.persianagroup.tv/
Logo
https://www.lyngsat.com/logo/tv/pp/persiana-latino-fr.png
Notes
No response

Streaming link: https://www.persianagroup.tv/live/persiana-latino


Using swifty boolean names in configuration?

More of a question/general discussion really, but what are the thoughts regarding use of Swifty bools (isDoingSomething vs doSomething) in the configuration file?
As a personal preference, they feel a bit out of place when in a yaml/json file. But I don't know if its me being nit picky or not. They also make it a bit harder to order the options alphabetically.
For the upcoming 0.1.0 release, I'm considering that we might just switch the style but I want other opinions first.

100% 👍 from me to change

cc @kean

I agree. They feel out of place in YAML. Please feel free to rename. 👍


git checkout doesn't create track on remote branch.

When pushing the branch, it ask what is the remote to track. it should be done automatically when created the branch for first time.

Did you create the branch in the command line or in Code?
This is standard git behaviour: not to assume things like this automatically.

I understand actually, thanks @joaomoreno


feat(#605): Prove That PHI Printing Workds Well For Inner Classes

In this PR I prove that printing PHI expressions for Inner classes works as expected and without errors.
The original problem with Inner classes was solved in a separate PR:
https://github.com/objectionary/jeo-maven-plugin/pull/612
Closes: #605.

PR-Codex overview
The focus of this PR is to add an integration test for a Java application using Takes Framework and to include a plugin for converting Xmir to Eo language.
Detailed summary

Added integration test for Takes Framework
Included eo-maven-plugin for converting Xmir to Eo language
Configuration set to process Xmir files during process-classes phase

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@rultor merge

@rultor merge

@volodya-lombrozo OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@volodya-lombrozo Done! FYI, the full log is here (took me 8min)


Remove automerge CI workflow

I think it's better for now if we are aware of every PR, even/especially little patch updates to dependencies

That's good for me, anyways it never really works.


Translate the program into another language

Is your feature request related to a problem? Please describe.
I want to translate the program into another language. But I can't understand the source code.
I think that the message used in the program is hard-coded in the source code, so please change it to refer to the translation file.
Adding translations to each source code is a hassle.
Describe the enhancement you'd like
Create translate file such as .po file

Hello! This is currently working on and it's planned to release in version 3.9.1.
Currently, in the upcoming 3.9.0, we added Simplified Chinese as a language option and we're planning to move all the texts to a translation file soon.

Hello! This is currently working on and it's planned to release in version 3.9.1.
Currently, in the upcoming 3.9.0, we added Simplified Chinese as a language option and we're planning to move all the texts to a translation file soon.

Hi, 3.9.1 version has been released, but translation file not found.
How soon will the translation file be available?

We released 3.9.1 as a hotfix due to a crashing issue, but the translation file will be implemented in 3.9 eventually.

https://user-images.githubusercontent.com/91040195/134793540-5a24311c-69de-4f3f-9990-24999c8cfbfd.mp4
I got some errors when trying to change the language.

@21Suga This is related to the transparency effects. Disabling them (right above the language dropdown menu) should fix the issue!

Closing this issue in favor of #112.


(#149) Update Organizational Documentation for trials

Remove mentions of trials needing to manually download packages from their trial emails; we will no longer need those steps to differ from fully licensed customers when the licensed package feed is updated.
Included a few small formatting / minor spelling fixes that I happened to catch as I was looking through.
Fixes #149

@pauby @ferventcoder are either of you in a position to review this PR?  Thanks!

@ferventcoder @pauby asking again for some input on this PR prior to merging in.  Thanks

Just a thought but can we get rid of the MSP step labels as we longer offer discrete MSP licensing?

@ryanrichter94 tbh this entire guide needs rewritten / split out into multiple separate guides, at which point we'd remove the MSP sections, I think.
Probably best done in a future PR rather than this one though. 🙂

@vexx32 I'll raise a separate PR for work to split the Org Deployment Guide and get it in a better place. In regards to what this PR covers LGTM.

@vexx32 @adilio @ryanrichter94 if you are all happy with the changes here, there is no requirement (unless you are looking for clarification from me) to wait on me clicking the merge button.  You should all have access to do this, so feel free to go ahead.  Once merged, and the build completes, the changes should pretty much immediately be available on the site.  If anyone has any questions about the process feel free to ask, but it has been designed that anyone on the team should be able to push out some docs changes.
For now, I have enabled auto-merging of this PR, so once the PR build completes successfully, it should automatically merge and push it out.