Is it possible to share error handler middleware between express instances?

When using another express instance as middleware, the second instance's .use works fine, except as an error handler, with err as first argument
var app = require("express")()
var app2 = require("express")()
app.get("/", function(req, res){
  res.send("normal response")
})
app.get("/err", function(req, res){
  throw new Error()
})
app2.use(function(req, res, next){
  res.send("404") // this function is called when visiting non-existent route
})
app2.use(function(err, req, res, next){
  res.send("error") // this function is never invoked
})
app.use(app2)
app.listen(3000)

Hi @jshawl
Yes you right but i think the better way to share or customize the error handler and some other middleware in general is in using express router. Below i post an example to be more clear:
'use strict';
const express = require('express');

const app = express();

function myCustomErrorHandler(err, req, res, next) {
    // TODO: intercept error - parse it and give some response
    // Just for example sent the err back in the response
    res.send(err.message);
}

const mySubApp1 = express.Router();
const mySubApp2 = express.Router();
const mySubApp3 = express.Router();

mySubApp1.get('/', function (req, res, next) {
    res.send('Normal response in sub app 1');
});
mySubApp1.get('/err', function (req, res, next) {
   throw new Error('Error in sub app 1');
});

mySubApp2.get('/', function (req, res, next) {
    res.send('Normal response in sub app 2');
});
mySubApp2.get('/err', function (req, res, next) {
    throw new Error('Error in sub app 2');
});

mySubApp3.get('/', function (req, res, next) {
    res.send('Normal response in sub app 3');
});
mySubApp3.get('/err', function (req, res, next) {
    throw new Error('Error in sub app 3');
});
mySubApp3.use(function(req, res, next){
    res.send("404 in sub app 3");
});
mySubApp3.use(function(err, req, res, next) {
        // TODO: intercept error - parse it and give some response
        // Just for example sent the err back in the response
        res.send(err.message + ' Error handler of sub app 3');
    }
);

app.use('/app1', mySubApp1);
app.use('/app2', mySubApp2);
app.use('/app3', mySubApp3);

app.use(function(req, res, next){
  res.send("404");
});
app.use(myCustomErrorHandler);

app.listen(3000);

In the example SubApp1 and SubApp2 share the same 404 and error handler, while SubApp3 has its own.
In case you have real necessity to use two express app i think that the best choice is to use vhost you can find an example here.
I hope that this help you.

This is about Router. What about the const realSubApp = express()?

Sorry the original question was never answered. Here is a Similar issue with some good answers that should help: https://github.com/expressjs/express/issues/2973


Refreshes token for intellisense

ADS will receive a refresh token notification from STS and then it will send a notification back with the updated refresh token.
STS PR: https://github.com/microsoft/sqltoolsservice/pull/1476

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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 42.237%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
27788

Relevant Lines:
61561

💛  - Coveralls


Enhancement ideas

Love the module, two ideas that would be nice to consider for future updates:

from the readme it doesn't sound like exhaustion effects are dependent on the PC constitution score as written in the books, if that's the case might be nice to include.

would be nice to include a setting that allows for successful foraging to "satisfy" the hunger needs for the day. This would streamline things a bit so you don't have to add foraged food just to remove for eating. Could have it be a simple button on the dialogue

that's true - I haven't investigated it fully but I think the SRD rules ignore constitution but the 5e core rules include it. I'm planning to tackle it in a future release!
This is a great idea.


CI May Depend on Local Branch

When running the notebook tests for #516, I noticed that the test failed because the CI would checkout the name of the branch on origin remote git checkout -q <branch>, even though the branch was on my fork. This may cause confusion for PRs.
  Running command git checkout -q flores200_refresh
  error: pathspec 'flores200_refresh' did not match any file(s) known to git
  error: subprocess-exited-with-error

  × git checkout -q flores200_refresh did not run successfully.
  │ exit code: 1
  ╰─> See above for output.

https://github.com/mlcommons/croissant/actions/runs/7905586788/job/21578542985

@mkuchnik Michael, thanks creating the issue! It should now be fixed.


rethink about the static interface

Our current decision on the static interface is that a go signal is triggered for exactly 1 cycle and an output is produced n cycles later, where n is the static<n>  annotation for the static component.
From our synchronous meeting, we decided the way we could implement this was the following: once we have compiled the inlined the control into a single static group, we make the assignments continuous and add the following guards:

fsm transition from 0 to 1 is guarded by the comp.go. All other fsm  transitions are not guarded.
All other assignments that were in the single static group should by guarded by comp.go | fsm > 0. fsm > 0  is needed because we no longer necessarily need the go  signal asserted for comp to be active: we just need to know the fsm is “running”. comp.go  is needed because fsm will equal 0 when the component is inactive: we should make sure assignments are not triggered when this is the case.

We think this implementation would work but it incurs a cost of an ‘or’ per assignment, which could potentially increase LUT usage. There are also other concerns/ to think about:

The inconsistency between the triggering of static groups and the triggering of the static component. Calyx’s group’s go-done interface is consistent with its invocation interface in the sense that both the group’s interface and the invocation interface have go signals that trigger for the entire execution duration. However, our compilation of static<n> invoke comp would have compile to a static<n> group with  comp.go asserted for cycle 0 , and then de-asserted for cycles [1,n) . This is expected, but just something we should take note of.
For  static<n> invoke comp (// comp's other inputs)(...) , our current decision would need  comp.go  asserted for exactly one cycle, while the // comp's other inputs must be asserted for n cycles (unless we latch // comp's other inputs), which makes using the static interface potentially confusing.

The way we currently compile static invoke statements is turning the invoke into a static group with an annotated latency n that sets the component’s go signal high for n cycles (which is just an unguarded assignment inside the invoke group). The group also contains the assignments for the wiring of i-o ports active for n cycles. Regarding how pipelines would work, here is how static<n> pipelined_component might work. You should assert pipelined_component.go  for n  cycles to complete one stage of the pipeline. We think this idea may be workable?
(edit by Caleb for formatting)

All other assignments that were in the single static group should by guarded by comp.go | fsm > 0

This part doesn't make sense to me. Can we write down an example static group and work through what the compilation should look like?
Also, re: static invoke. It seems that you might just want something like:
static group inv_group<n> {
  comp.go = %0 ? 1'd1;
  comp.in0 = in0; comp.in1 = in1; ...
}

Said differently, the interface should make it trivial to reason about invoke compilation: it should just be a simple group.

re: re: static invoke. This is exactly how the invoke is compiled in the current implementation of the static interface. I guess my point is, if users want to structurally invoke a component for some reason, then our interface creates a weird discrepancy(?) between the time that the go signal is held and the inputs are held, which is kind of unnecessary.

Ah, I see! I think this is okay, however, because a static interface supports pipelining. Each time we set, static_comp.go = 1, we are sending a "token" that says, "please start a new computation." If we asserted the go signal for n cycles, we would be starting n new computations.
Asserting for go for 1 cycle and inputs for n cycles is a conservative way interface that says, "we don't know when exactly the inputs are used so we're going to assert them for the full latency". I think you should read the Filament paper to get a better sense of these kinds of interfaces. Filament's types really make it clear what is going on with interfaces like these.

All other assignments that were in the single static group should by guarded by comp.go | fsm > 0

This part doesn't make sense to me. Can we write down an example static group and work through what the compilation should look like?

After thinking about this, I think we should adjust our idea slightly. @paili0628 feel free to chime in on this.
Dynamic Component Compilation
Suppose this is our component, just before wire-inliner runs
component comp() {
  wires {
    group seq0 {
      ...
    }
  }
  control {
    seq0;
  }
}

When wire-inliner runs, it compiles to:
component comp(go: 1) {
  wires {
    seq0_go.in = go;
  }
  // control is empty
}

And seq0_go.out guards all the assignments in seq0.
For static components, we don't want this to be the case: there are some cases where the comp.go signal is not asserted (but was asserted a few cycles ago), but we still want to the component to be running.
Proposed Static Component Compilation
component comp(go: 1) {
  wires {
    seq0_go.in = go | fsm > 0; // if seq0's fsm > 0, then that means the fsm is "already running"
  }
  // control is empty
}

And seq0_go.in is still guarding all of seq0's assignments. So the comp.go | fsm > 0 is indirectly (through a wire) guarding seq0's assignments.
Of course, this shouldn't include the assignments to the fsm, which should be guarded by comp.go for 0->1 and unconditional for everything else.
There will be some coding/engineering challenges with this, but does this make sense overall @rachitnigam @paili0628?

This makes sense but the guard has to be constructed at pass wire-inliner which makes it hard to pull out the fsm for the static group.

seq0_go.in = go | fsm > 0

I still don't understand what's going on here. If seq0 used to be a static group, then this will attempt to continuously execute seq0 every cycle right?

It will not. seq0 will execute for n cycles every time the go signal is up, where n is the annotated latency.

From the synchronous discussion:
static component comp() {
  wires {
    static<4> group seq0 {
        mult.go = %1 ? 1'd1;
        mult.left = 1;
        mult.right = 2;
    }
  }
  control {
    seq0
  }
}

// =>

static component comp() {
  cells {
    s_fsm = std_reg(4);
    @control start = std_wire(1);
  }
  wires {
    start.in = go;
    mult.go = %1 ? 1'd1;
    mult.left = %[0:4] ? 1;
    // =>
    mult.go = s_fsm.out == 1 ? 1'd1;
    mult.left = %0 | %[1:4] ? 1;
    // =>
    mult.left = start.out | (s_fsm.out >= 1 & s_fsm.out < 4) ? 1;
  }
  control {
    seq0;
  }
}

The compilation strategy needs to treat %0 as a special step because it needs to forward the value from the go signal.

@calebmkim could you share your notes from the synchronous meeting today? Also, if we have made a decision on how to proceed, let's change the labels.

Static islands (i.e., static control within a dynamic component) compilation doesn’t need to change for now, since they will be compiled with a wrapper and will be treated like any other dynamic group. Note that the assignments in a static islands will (at least indirectly) be guarded by the (dynamic) component’s go signal. Eventually we want to change this: we only want to have to trigger a static island’s go signal for one cycle, and the FSM will control execution from there.
Static components get a slightly fancier FSM.
The 0->1 is guarded by the static_comp.go signal, all other FSM transitions are unguarded.
Also, if a guard includes %[0:n], then we have to separate it out into %0 | %[1:n], and then replace %0 with static_comp.go.

@paili0628 and I just met to discuss some implementation details. We have a more concrete plan now so I removed discussion needed tag.

Fixed by https://github.com/cucapra/calyx/pull/1759


RadioButtonItem glitches after changing the state

Compose 1.0.0, Windows 11
https://user-images.githubusercontent.com/5963351/143778528-0b8e1f1c-e20c-4bb4-aab8-e4cc75891bc5.mp4
See that after changing the item, and open the menu again, we can see the old state for some time

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Echo text being included on .hyper.js edit using VIM

[X] I am on the latest Hyper.app version

[X] I have searched the issues of this repo and believe that this is not a duplicate

OS version and name: OSX Sierra V 10.12.3

Hyper.app version: <IP_ADDRESS>4

Link of a Gist with the contents of your .hyper.js:  https://gist.github.com/rizowski/dc846b7d73313ba7b4ee250d45fabf89

Relevant information from devtools: Mac OS: CMD + ,

The issue is reproducible in vanilla Hyper.app: Not Vanilla

Issue
When I hit CMD + , to edit the preferences I get some of the echo statements prepended on top of my config. See screenshot:

I am using vim as my editor. If I execute the command the hyper uses to open .hyper.js I do not get this. The command being bash -c 'exec env ${EDITOR:=nano} ~/.hyper.js'
This issue didn't start happening until I upgraded to 1.3.0.

same thing is happening with default EDITOR being nano

Solved https://github.com/zeit/hyper/pull/1633 ✌


Feat: Home organisations section and organisations page

Checklist

[x] run npm run test and npm run benchmark
[x] tests and/or benchmarks are included
[x] documentation is changed or added
[x] commit message and code follows the Developer's Certification of Origin
and the Code of conduct

this pr adds organisations section to home page and adds a page to display all organisations


Update MergeContent.php

In case we choose template and content box is empty, the code was throwing exception in mergeContent function so had to pass blank string to avoid it.

Thanks for the PR, but this was just fixed yesterday https://github.com/mettle/sendportal-core/pull/34


Support for generating string discriminated unions

Hey @arthurfiorette thank you for the awesome utility here! We're planning on using it at Replo to auto-generate types for the json models in our database. I was wondering if you'd be willing to accept a PR which implemented support for discriminated unions of strings as well as json (happy to help with the implementation if you can point me to the right place). Our use case is:
// schema.prisma
model MyModel {
    /// [ModelKind]
    kind                          String?          @db.VarChar(512)
    // ...
}

// index.ts
declare global {
  namespace PrismaJson {
    // ...
    type ModelKind =
      | "page"
      | "article"
      | "section";
  }
}

Ideally, we'd like the generated client to have all MyModel operations return types have the kind be typed as the ModelKind DU. Currently, this gives this not supported error, so I assume supporting this would involve handing the String type correctly there and outputting the alias.
Let me know what you think! If you're down to accept something like this, let me know if that implementation seems correct and we can start working on a prototype 👍

Hi @noahsark769, awesome idea! I'd love to implement it!

You'd probably start by changing some Ifs that filters out non Json field types, and then adding your case to this function.
But, I think a new syntax for string literals or even some checks should be made to prevent you assign a non string literal type to a string, which will only throw an error at runtime.
As you can see, the replace signature handle all variations a field can have, Like User, Prisma.UserFindManyArgs and so on. If you get some complex fields, like StringFilter, using a more generic approach should do the job. (Like the Update<T> generated type and its usage)
I'm currently moving to another state, but i'll try to merge it asap. :)

Alright, started on a draft PR at #39, managed to get local development set up and tests passing for the simple string case, will work on implementing support for more complex filter types and unions soon!


loader is not executed in dependency of dependency

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
loader is ignored when module is not required directly from entry file
If the current behavior is a bug, please provide the steps to reproduce.

I use js-aruco which is browser only. To shim it, I created 2 modules:
// module cv.js
module.exports = require('exports-loader?CV!../js-aruco/src/cv.js')
// module ar.js
module.exports = require('exports-loader?AR!imports-loader?CV=./cv.js!../js-aruco/src/aruco.js')

In my app I require the ar-module
var AR = require('modules/ar.js')

However - in the bundled code, no export for the cv module is added.
When I require the cv module directly from my entry, I end up with the code of the cv-module TWICE in the bundled file - one with export and one without. However, ar still does not find it because it tries to load the broken version
PS: An export for the ar module is added correctly
What is the expected behavior?
the loader should get executed for cv.js. Currently it just gets ignored.
Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
webpack 3.0.0
win7
node 6.10.3
PS: My webpack config consists of entry and output - so nothing special there

The imports-loader is relative to the decorated file.
imports-loader?CV=./cv.js
imports-loader?CV=modules/cv.js

That dies not fix it. Instead webpack complains about that it cant find the module. cv.js and ar.js are both in the modules. So it already was relative to the decorated file. So or so: The import loader should at least do something on this directive. I looked into the loader and loged which files are recognised and it just doesnt get executed in my case


Washing machine: Incorrect (negative) temperature in cold water program

The problem
Hi, in a Miele washing machine (model WWI860) when the water temp for the washing program is set to cold, in HA the target temperature is reported as -327.66 °C (works OK in any other temperature setting).
Maybe it should be set to 0 °C or N/A if possible.
Thanks!
Version of miele integration having the issue?
miele-0.0.25
Version of Home Assistant Core having the issue?
core-2022.10.2
Anything in the logs that might be useful for us?
No response
Additional information
No response

The Miele API uses -327.68 as a marker for unavailable value in certain conditions. I dont recognise -327.66 . If would be very helpful if you can get a diagnostic download from the device page in HA when this erroneous target temperature is displayed. Please upload the downloaded file to this issue.

Diagnostic attached
miele-73ac42db612e3ec222d29a38d6c1ef29-Washing machine-41d331ef695a1a5ee2318b356047bbfa.json.txt

Fixed.
Target temp will be displayed as unknown


Auto adjust split transactions not working correctly

Auto adjust split transactions
System Settings (Required)
ToolKit Version: 1.5.0
Operating System (Mac/Windows/Etc): Win10
Browser (Chrome/Firefox/Safari): Chrome
Browser Version: 63.0.3239.132
Other Extensions: LastPass, Office Online, AdBlock for youtube,
Export of Toolkit Settings (Bottom Left of Settings Page)

Settings Export
[{"key":"AccountsDisplayDensity","value":"1"},{"key":"AccountsEmphasizedOutflows","value":true},{"key":"AccountsStripedRows","value":true},{"key":"ActivityTransactionLink","value":true},{"key":"AdditionalColumns","value":true},{"key":"AdjustableColumnWidths","value":true},{"key":"AutoCloseReconcile","value":true},{"key":"AutoDistributeSplits","value":false},{"key":"BetterScrollbars","value":"0"},{"key":"BudgetBalanceToZero","value":true},{"key":"BudgetQuickSwitch","value":true},{"key":"CalendarFirstDay","value":"0"},{"key":"CategoryActivityCopy","value":false},{"key":"CategoryActivityPopupWidth","value":"2"},{"key":"ChangeEnterBehavior","value":true},{"key":"CheckCreditBalances","value":true},{"key":"CheckNumbers","value":true},{"key":"ClearSelection","value":true},{"key":"CollapseSideMenu","value":true},{"key":"ColourBlindMode","value":false},{"key":"CurrentMonthIndicator","value":true},{"key":"CustomFlagNames","value":false},{"key":"DaysOfBuffering","value":false},{"key":"DaysOfBufferingHistoryLookup","value":"0"},{"key":"DisableToolkit","value":false},{"key":"DisplayTargetGoalAmount","value":"0"},{"key":"EditAccountButton","value":"2"},{"key":"EnableRetroCalculator","value":true},{"key":"EnterToMove","value":false},{"key":"GoalWarningColor","value":false},{"key":"GoogleFontsSelector","value":"0"},{"key":"HideAccountBalancesType","value":"0"},{"key":"HideAgeOfMoney","value":true},{"key":"HideHelp","value":false},{"key":"HideReferralBanner","value":false},{"key":"ImportNotification","value":"2"},{"key":"LargerClickableIcons","value":true},{"key":"MonthlyNotesPopupWidth","value":"1"},{"key":"NavDisplayDensity","value":"1"},{"key":"PrintingImprovements","value":true},{"key":"PrivacyMode","value":"0"},{"key":"QuickBudgetWarning","value":true},{"key":"ReconciledTextColor","value":"1"},{"key":"RemovePositiveHighlight","value":true},{"key":"ResizeInspector","value":true},{"key":"RowHeight","value":"2"},{"key":"RowsHeight","value":"1"},{"key":"RunningBalance","value":"1"},{"key":"SeamlessBudgetHeader","value":true},{"key":"ShowCategoryBalance","value":false},{"key":"ShowIntercom","value":true},{"key":"SplitKeyboardShortcut","value":true},{"key":"SquareNegativeMode","value":true},{"key":"StealingFromFuture","value":true},{"key":"TargetBalanceWarning","value":true},{"key":"ToBeBudgetedWarning","value":true},{"key":"ToggleMasterCategories","value":true},{"key":"ToggleSplits","value":true},{"key":"accountsClearSelection","value":true},{"key":"accountsDisplayDensity","value":"1"},{"key":"accountsEmphasizedOutflows","value":true},{"key":"accountsRowHeight","value":"2"},{"key":"accountsSelectedTotal","value":false},{"key":"accountsStripedRows","value":true},{"key":"activityTransactionLink","value":true},{"key":"betterScrollbars","value":"0"},{"key":"budgetBalanceToZero","value":true},{"key":"budgetProgressBars","value":"0"},{"key":"budgetQuickSwitch","value":true},{"key":"budgetRowsHeight","value":"1"},{"key":"calendarFirstDay","value":"0"},{"key":"categoryActivityPopupWidth","value":"2"},{"key":"changeEnterBehavior","value":true},{"key":"checkCreditBalances","value":true},{"key":"checkNumbers","value":true},{"key":"closeReconcileWindow","value":true},{"key":"collapseExpandBudgetGroups","value":true},{"key":"collapseSideMenu","value":true},{"key":"colourBlindMode","value":false},{"key":"compactIncomeVsExpense","value":true},{"key":"currentMonthIndicator","value":true},{"key":"daysOfBuffering","value":false},{"key":"daysOfBufferingHistoryLookup","value":"0"},{"key":"editButtonPosition","value":"2"},{"key":"enableRetroCalculator","value":true},{"key":"enlargeCategoriesDropdown","value":true},{"key":"enterInRegisterNow","value":true},{"key":"exportTransactions","value":false},{"key":"goalIndicator","value":true},{"key":"goalIndicatorWarningColor","value":true},{"key":"googleFontsSelector","value":"0"},{"key":"hideAOM","value":true},{"key":"hideAccountBalancesType","value":"0"},{"key":"hideHelp","value":false},{"key":"highlightNegativesNegative","value":true},{"key":"importNotification","value":"2"},{"key":"incomeFromLastMonth","value":"1"},{"key":"l10n","value":"0"},{"key":"largerClickableIcons","value":true},{"key":"monthlyNotesPopupWidth","value":"1"},{"key":"navDisplayDensity","value":"1"},{"key":"options.dark-mode","value":false},{"key":"pacing","value":"0"},{"key":"popupCalculator","value":true},{"key":"printingImprovements","value":true},{"key":"privacyMode","value":"0"},{"key":"reconciledTextColor","value":"1"},{"key":"removePositiveHighlight","value":true},{"key":"removeZeroCategories","value":true},{"key":"reports","value":true},{"key":"resizeInspector","value":true},{"key":"rightClickToEdit","value":true},{"key":"runningBalance","value":true},{"key":"seamlessBudgetHeader","value":true},{"key":"showIntercom","value":true},{"key":"spareChange","value":true},{"key":"splitKeyboardShortcut","value":true},{"key":"splitTransactionAutoAdjust","value":true},{"key":"squareNegativeMode","value":true},{"key":"stealingFromNextMonth","value":true},{"key":"swapClearedFlagged","value":false},{"key":"toBeBudgetedWarning","value":true},{"key":"toggleSplits","value":true},{"key":"toggleTransactionFilters","value":"2"},{"key":"warnOnQuickBudget","value":true}]

Steps to Reproduce the Behavior

Take existing downloaded transaction
Edit and hit "split transactions" button
add category and add second category, the remaining balance does not show up on the new category line.

Expected Behavior
when i add a new category line i thought the remaining balance shows up in the new category line money amount automatically.
Actual Behavior
The new category line added has a zero amount in the money column. although underneath in the total balance remaining it has the remaining amount.

Just to clarify things. This issue is related to the Auto Adjust Split Transactions feature not the Add Auto-Distribute Button to Split Transactions feature. See issue #1180 for a fix related to the auto distribute button.

@joshmadewell I believe you contributed this feature. How did you envision it working? Was the intent for each empty split (no value or $0.00) or just the first empty split to be set to the remainder? Right now, when initially entering the total, that same value is entered into the first empty split. As I tab to the category field of the first split and then into the outflow field, the same value is put in the second empty split and the remainder is set to the same value on the inflow side of things. It all seems whacky to me so I'd like to capture what the "rules" are and make the feature follow them.

I agree with you about how the feature should work. That makes more sense than how it currently works. My fix'll encapsulate the logic you've outlined in your response.

@joshmadewell what do you think about not updating the remaining splits until the user tabs out of the split they're entering an amount into?

@dbaldon are you still working on this one?

@jwright712 I haven't been able to work much on it. It seems like there were some changes in the same code area since I started looking at it that changed what I thought needed to be done to fix the problem but it's been so long since I've looked at it that I could be thinking of another issue. If you want to take a look at it feel free. I've un-assigned myself from the Issue.

Closing in lieu of #1756.


Radar chart labels overlapping

It would be nice if they could wrap, or adjust their position based on length/space.
Note: chart has 50 different data points.

@tannerlinsley I think this is a good candidate for a 2.1 feature. Thoughts?

Closing. These labels won't autowrap, but they can be rendered on multiple lines by setting the labels as arrays of strings
labels: [ 'test', ['line 1', 'line 2']]

It would be amazing if this request could be revisited and labels given further styling optiosn for radial charts.
I've been searching high and low trying to find a way to push them further out from the graph, or something to that effect.


Asking Multiple times root's password on 'cook'

Hi,
When cooking the server it ask me multiple times the root's password.
Checking online I found is caused by Rsync. Is that a natural behavior?, can it be automated?.
Thanks.
I paste here the cook sequence:
bundle exec knife solo cook root@<ip>
Running Chef on <ip>...
Checking Chef version...
Enter the password for root@<ip>:
Installing Librarian cookbooks...
Uploading the kitchen...
root@<ip>'s password:
root@<ip>'s password:
root@<ip>'s password:
root@<ip>'s password:
root@<ip>'s password:
root@<ip>'s password:
root@<ip>'s password:
Generating solo config...
root@<ip>'s password:
Running Chef...

Because you didn't set up ssh public key.

Hi @arturictus
As @cvandermeer mentioned: you could solve this by adding the SSH key of your workstation (located in ~/.ssh/id_rsa.pub) to the authorized_keys file on your server located at /root/.ssh/authorized_key
If you add your personal key to the root account, it will not ask you a password anymore.
Does this help?
Michiel

Yeah! :+1:
Thanks, that make sense :smile: .

Great! :) I'll close this issue.


Add single page for initial signup form

Initial Signup Form
https://www.notion.so/uwblueprintexecs/Frontend-Initial-Sign-up-form-ca1f7c0f2d0448ccb7542c43de8c8d0a
Added initial signup form where user decides if they are a parent or user
Steps to test
Run the app locally and head over to http://localhost:3000/en/signupform to see the new page
My PR name is descriptive and in imperative tense
I have run the linter
I have requested a review from the PL, and/or other devs who have background knowledge on this PR or who will be building on top of this PR

@mahadzaryab1 Now that the high fidelity designs are done, do you think we should update this prior to merging into staging or do you think we should merge this in and then have another PR to update to high fidelity designs? I'm okay with either.

@mahadzaryab1 Now that the high fidelity designs are done, do you think we should update this prior to merging into staging or do you think we should merge this in and then have another PR to update to high fidelity designs? I'm okay with either.

Let's merge and then update this


Add Accuracy

We previously exposed accuracy information on TypedRowset, which is now deprecated.  Result rowsets now use the standard DB-API tuples format, and optionally return Pandas data frames, with neither API having a place to store accuracy information.
Proposal is to add an API on private_reader that will parse a query and calculate the 95% accuracy interval for each column in the query, returning the bounds as a vector.
query = 'SELECT COUNT(*) FROM PUMS.PUMS'
private_reader = PrivateReader(reader, meta, 1.0)
accuracy = private_reader.get_accuracy(query)
print(accuracy[0])

Because we need metadata to calculate sensitivity, get_accuracy will require parsing and symbol resolution.  The code that calculates sensitivity is currently in the execute() method of PrivateReader, so we should pull that out into a shared routine that can be called from both methods.  One option would be to add sensitivity to Query.load_symbols.
https://github.com/opendp/smartnoise-sdk/blob/main/papers/DP_SQL_budget.pdf

We should allow arbitrary accuracy bounds to be requested, such as 95% and 99%.  One way to expose this would be:
accuracy = private_reader.get_accuracy(query, alphas=[0.01, 0.05])

@joshua-oss thanks so much for your help getting this implemented. The calling pattern with a list of alphas to calculate would be incredibly helpful.

I'm realizing that the above calling pattern would work for only SUM and COUNT queries, since the other statistics need the noisy count (denominator) to compute accuracy.  The only way to get the noisy count is to actually execute the query.  We could execute the query in get_accuracy, but then the calling pattern would result in the query being executed twice.  So it seems best to just return accuracy with the execute() method.  Two possible approaches:

Allow execute() to return the rowset and the accuracy:

result, accuracy = private_reader.execute(query, alphas) # has accuracy
result = private_reader.execute(query) # no alphas provided, so no accuracy

This has the advantage of being consistent with current calling patterns, and the path without accuracy would continue to conform to DB-API interface.  It has the disadvantage that the number of return values will differ based on whether or not alphas are passed in.  In practice, this shouldn't be a problem, because the caller will only pass alphas when expecting two return values.  But this approach is probably not pythonic.

Make a new method, e.g. execute_with_accuracy():

result, accuracy = private_reader.execute_with_accuracy(query, alphas)
result = private_reader.execute(query) #  no accuracy

This has the advantage of being explicit, but feels more cumbersome.
Another important implication of statistics needing the noisy count for accuracy: we will need to return accuracy bounds for each row of the output.  For example, if we do SELECT educ, AVG(income) FROM PUMS GROUP BY educ, the partitions with fewer members will have worse accuracy.  In this PUMS example, there are ~13 distinct values for educ, and the sizes of each partition vary greatly.  We would need to return ~13 rows of accuracy information in this case.  For queries with multiple columns, the accuracy return value would be the same length and width as the query results rowset.  I think this is fine, and we could provide code samples to show how to use zip() to combine accuracy information with the noisy values.

@joshua-oss, could you clarify the problem about running the query twice? Is this a computing problem or a methodology problem?

@ClaireMcKayBowen, the issue with running query twice is just that the queries may be expensive.  We do have a capability to  cache query output for multiple issues of the same query, but this is geared more towards very high numbers of runs for fairly small result sets (e.g. 10,000 runs of same query in the stochastic evaluator).  In practice, we have some queries that operate on petabytes of data, returning millions of partitions, so caching wouldn't be feasible, and the computation costs enough money to matter.
Regarding the last paragraph, the output would have one row per aggregate partition, and one column for each alpha, for each column.  This means we also need to decide how to group the results.  For example, if we had something like SELECT race, AVG(income), AVG(educ) GROUP BY race, requesting two alphas, we have a few choices for how to return:

Each row shows two accuracy columns per output column, in column order:

('race99', 'race95', 'educ99', 'educ95', 'income99', 'income95'),
(None, None, 3.8, 3.6, 2.6, 2.4)`

In this example, we return 2 None values for the accuracy of the grouping column, to preserve column order.

Each row has one accuracy column per output column, and the column has a tuple that has the same number of items as the alphas passed in:

('race', 'educ', 'income'),
( [None, None], [3.8, 3.6], [2.6, 2.4])

We return multiple accuracy results as a list, with each item in the list being for each alpha, in the same order passed in:

alphas = [0.01, 0.05]
result, accuracy = private_reader.execute(query, alphas)
accuracy99, accuracy95 = accuracy

print(accuracy95)

('race', 'educ', 'income'),
( None, 3.6, 2.4)

Note that all of these approaches can optionally return accuracy as Pandas data frame(s), the same as query results can come back as Pandas.

@joshua-oss Thank you for taking the time to explain this to me! This makes sense.

Thinking about this more, it might make sense to put the alphas on the PrivateReader.  Assuming we adopt the pattern of #377, this would look something like:
conn = pyodbc.connect(dsn)
privacy = Privacy(epsilon=1.0, alphas=[0.1, 0.5])
private_reader = PrivateReader(conn, privacy, meta=meta)
result, accuracy = private_reader.execute_with_accuracy(query)

This has the advantage that alphas don't need to be passed on every call to execute().  This is using the second pattern for accuracy above, to avoid inconsistent number of return values.  The long method name still feels cumbersome, perhaps we could find a better name.  Maybe execute_accuracy().  Or we could go ahead and overload execute() as above.
result, accuracy = private_reader.execute(query) # works if alphas set on private_reader, fails otherwise
result = private_reader.execute(query) # works if no alphas on private_reader, fails otherwise

This means the caller would need to remember if alphas were set on the PrivateReader instantiation, and would need to go change all lines that call execute if the presence of alphas list changes.  For example, if the user updated the code that instantiated private reader to add  alphas, but then forgot to capture accuracy on execute, the call would fail.  One way to handle this would be with a positional parameter on execute that specifies that accuracy will be returned, like:
result, accuracy = private_reader.execute(query, True) # always works; returns empty accuracy list if alphas not set
result = private_reader.execute(query) # always works

@joshua-oss Just my thoughts: Agree that setting the alphas on the PrivateReader seems easier than having to pass it to every execute() call. And execute_with_accuracy() or execute_accuracy() don't feel that cumbersome, at least compared to the issues with overloading execute() you outlined.

Accuracy is now merged and published to PyPi.  Code samples of usage:
from opendp.smartnoise.metadata.collection import CollectionMetadata
from opendp.smartnoise.sql.parse import QueryParser
from opendp.smartnoise.sql.privacy import Privacy
import pandas as pd
import numpy as np

from opendp.smartnoise.sql import PrivateReader

meta_path = 'datasets/PUMS.yaml'
csv_path = 'datasets/PUMS.csv'

pums = pd.read_csv(csv_path)
meta = CollectionMetadata.from_file(meta_path)
delta = 1/ (1000 * np.sqrt(1000))
privacy = Privacy(epsilon=1.0, delta=delta, alphas=[0.05, 0.01, 0.5])

reader = PrivateReader.from_connection(pums, privacy=privacy, metadata=meta_path)
query = 'SELECT COUNT(income) AS n FROM PUMS.PUMS'

# first, execute without accuracy, loading to a pandas df
print(reader.execute_df(query))

# next, execute with accuracy, using the row iterator syntax
result = reader.execute_with_accuracy(query)
for row, accuracies in result:
    acc95, acc99, acc50 = accuracies
    print(f"{row} with 95% +/-{acc95[0]}")

# now execute with pandas df syntax
result = reader.execute_with_accuracy_df(query)
res, accuracies = result
acc95, acc99, acc50 = accuracies
print(res)
print()
print(acc95)

# now execute 30 times and check odometer
for _ in range(30):
    reader.execute(query)

print(f"Odometer after 30 more runs: {reader.odometer.spent}")

"""
The following code shows how to run multiple trials of a SQL query
more efficiently.  This uses the internal API _execute_ast with the
private setting cache_exact to ensure that the exact SQL query runs
only once.  This is not the recommended syntax for calling accuracy,
but should speed up sampling substantially when large numbers of draws
of the same query are desired.
"""

### Count

query = 'SELECT COUNT(income) AS n FROM PUMS.PUMS'
actual = 1000

q = QueryParser(meta).query(query)

reader = PrivateReader.from_connection(pums, privacy=privacy, metadata=meta_path)

res = reader.execute_with_accuracy(query)

for row, accuracies in res:
    n95, n99, n50 = accuracies
    print(f"{row[0]} --> {n95[0]}, {n99[0]}, {n50[0]}")

counts = []
trials = 1000
for _ in range(trials):
    res = reader._execute_ast(q, cache_exact=True, accuracy=True)
    row, acc = res[1]
    counts.append(row[0])

upper95 = actual + n95[0]
lower95 = actual - n95[0]
upper99 = actual + n99[0]
lower99 = actual - n99[0]
upper50 = actual + n50[0]
lower50 = actual - n50[0]

out95 = sum([c <= lower95 or c >= upper95 for c in counts])
out99 = sum([c <= lower99 or c >= upper99 for c in counts])
out50 = sum([c <= lower50 or c >= upper50 for c in counts])

print(f"{out95/trials} of values are outside the 95% range")
print(f"{out99/trials} of values are outside the 99% range")
print(f"{out50/trials} of values are outside the 50% range")

### Sum

query = 'SELECT SUM(age) AS n FROM PUMS.PUMS'
actual = 44797

q = QueryParser(meta).query(query)

reader = PrivateReader.from_connection(pums, privacy=privacy, metadata=meta_path)

res = reader.execute_with_accuracy(query)

for row, accuracies in res:
    n95, n99, n50 = accuracies
    print(f"{row[0]} --> {n95[0]}, {n99[0]}, {n50[0]}")

counts = []
trials = 1000
for _ in range(trials):
    res = reader._execute_ast(q, cache_exact=True, accuracy=True)
    row, acc = res[1]
    counts.append(row[0])

upper95 = actual + n95[0]
lower95 = actual - n95[0]
upper99 = actual + n99[0]
lower99 = actual - n99[0]
upper50 = actual + n50[0]
lower50 = actual - n50[0]

out95 = sum([c <= lower95 or c >= upper95 for c in counts])
out99 = sum([c <= lower99 or c >= upper99 for c in counts])
out50 = sum([c <= lower50 or c >= upper50 for c in counts])

print(f"{out95/trials} of values are outside the 95% range")
print(f"{out99/trials} of values are outside the 99% range")
print(f"{out50/trials} of values are outside the 50% range")

### Avg

query = 'SELECT AVG(age) AS age FROM PUMS.PUMS'
q = QueryParser(meta).query(query)
actual = 44.797

#query = 'SELECT AVG(age) AS age FROM PUMS.PUMS WHERE educ > 12'
#q = QueryParser(meta).query(query)
#actual = 47.532

reader = PrivateReader.from_connection(pums, privacy=privacy, metadata=meta_path)

res = reader.execute_with_accuracy(query)

for row, accuracies in res:
    n95, n99, n50 = accuracies
    print(f"{row[0]} --> {n95[0]}, {n99[0]}, {n50[0]}")

counts = []
trials = 1000
for _ in range(trials):
    res = reader._execute_ast(q, cache_exact=True, accuracy=True)
    row, acc = res[1]
    counts.append(row[0])

upper95 = actual + n95[0]
lower95 = actual - n95[0]
upper99 = actual + n99[0]
lower99 = actual - n99[0]
upper50 = actual + n50[0]
lower50 = actual - n50[0]

out95 = sum([c <= lower95 or c >= upper95 for c in counts])
out99 = sum([c <= lower99 or c >= upper99 for c in counts])
out50 = sum([c <= lower50 or c >= upper50 for c in counts])

print(f"{out95/trials} of values are outside the 95% range")
print(f"{out99/trials} of values are outside the 99% range")
print(f"{out50/trials} of values are outside the 50% range")

### Variance

query = 'SELECT VAR(age) AS n FROM PUMS.PUMS'
actual = 314.8987

q = QueryParser(meta).query(query)

reader = PrivateReader.from_connection(pums, privacy=privacy, metadata=meta_path)

res = reader.execute_with_accuracy(query)

for row, accuracies in res:
    n95, n99, n50 = accuracies
    print(f"{row[0]} --> {n95[0]}, {n99[0]}, {n50[0]}")

counts = []
trials = 1000
for _ in range(trials):
    res = reader._execute_ast(q, cache_exact=True, accuracy=True)
    row, acc = res[1]
    counts.append(row[0])

upper95 = actual + n95[0]
lower95 = actual - n95[0]
upper99 = actual + n99[0]
lower99 = actual - n99[0]
upper50 = actual + n50[0]
lower50 = actual - n50[0]

out95 = sum([c <= lower95 or c >= upper95 for c in counts])
out99 = sum([c <= lower99 or c >= upper99 for c in counts])
out50 = sum([c <= lower50 or c >= upper50 for c in counts])

print(f"{out95/trials} of values are outside the 95% range")
print(f"{out99/trials} of values are outside the 99% range")
print(f"{out50/trials} of values are outside the 50% range")


FMRC aggregation broken since v7.41

FMRC aggregation and regridding seems to have broken between Ferret v7.4 (4/18/18) and v7.41 (7/9/18).  Perhaps due to fixes for #1868, #1649, or #1657?  Or something else?
Marking this as urgent, since it breaks something we use -- and we don't have any good fallback versions that don't contain other bugs.
Here's what we had in v7.4:
 	NOAA/PMEL TMAP
 	FERRET v7.4 (optimized)
 	Linux 2.6.32-696.23.1.el6.x86_64 64-bit - 04/18/18
 	 7-Sep-18 16:02

yes? let agg_lister = "seq 1997 1999 | xargs -I@YEAR@ sh -c 'ls -1 /archive/rgg/SPEAR/SPEAR_c96_o1_pred_@YEAR@{01,07}/pp_ensemble/atmos/ts/monthly/1yr/atmos.@YEAR@??-??????.t_surf.nc'"
yes? fmrc ens_mean.agg = spawn(agg_lister)
yes? let/unit="degC"/title="NINO3 SST" nino3 = t_surf[x=150w:90w@ave,y=5s:5n@ave] - 273.15
yes? can view; ppl cross 1
yes? set view ul; shade/nokey/trans nino3
yes? set view ur; shade/nokey/trans/lev nino3[gt(tf_times)=tf_cal_t@fmrc]
yes? set view lr; plot/step=con/along=t/nokey nino3[gt(tf_times)=tf_cal_t@fmrc]

The resulting plot:

But in v7.41 through 7.421 (8/27/18) we get:
yes? set view ur; shade/nokey/trans/lev nino3[gt(tf_times)=tf_cal_t@fmrc]
 **ERROR: invalid command: auxiliary variable TF_TIMES has a F axis not found on variable NINO3
shade/nokey/trans/lev nino3[gt(tf_times)=tf_cal_t@fmrc]
Command file, command group, or REPEAT execution aborted

An error!
Let's look at the axes.    But now they have different axis names, and TF_CAL_F has a different size (36 rather than 6).
A related issue: we need test datasets for aggregations, so that testing, teaching, and bug-reporting are easier & more reproducible.  A good place to do this would be in the documentation, e.g.
https://ferret.pmel.noaa.gov/Ferret/documentation/users-guide/commands-reference/DEFINE#_define_data_agg
The docs should either provide the example files "tmp/fcst_1.nc" etc., or provide commands to create them.

I am checking if this may be an issue from changes to add the "spacing" as described at the end of #1663 - I suspect so.

This is due to the changes made in #1663 - obviously needs to be documented better.
A minimal superset axis of both the forecasted times and the times each forecast was made is now used, and the user decides how to fill in the gaps.
So adding in
let nino3fine = nino3[GT=TF_LAG_T@BIN,GF=TF_CAL_F@BIN]

and then plotting nino3fine gives the pyferret plot:

By the way, the @BI in the label gets deleted because I was using a non-Hershey font in PyFerret, and it thinks that is a Hershey font-change command that should be ignored.

This change is in the documentation under
https://ferret.pmel.noaa.gov/Ferret/documentation/users-guide/Grids-Regions/GRIDS#_4.2.7
but obviously also needs to be documented under
https://ferret.pmel.noaa.gov/Ferret/documentation/users-guide/commands-reference/DEFINE#_define_data_agg
along with a script to generate simple data files to play with.

The PyFerret plot using Hershey font and telling it to just plot N=1:37:6 in the last plot.

Thanks very much Karl, especially for taking the time to work with the actual GFDL files!  Glad it was a new "feature" rather than a bug -- and your plot is getting close to what we want.
The F-coordinates of the aggregation aren't quite right though.  Our forecasts start at 00Z on 1-Jan and 1-July of each year, as indicated by the starting TBOXLO values in the constituent datasets (d=7.1, 7.2, ..., 7.6).  You can also see these starting values with, for example, SHOW GRID/T t_surf[d=7.1].  The F-axis coordinates (the "cell centers") should thus be an uneven number of days apart, at exactly 1-jan-1997, 1-jul-1997, 1-jan-1998, 1-jul-1998, etc.  But instead they're evenly spaced (exactly 181 days apart), and a bit too close together, so that case #6 is at F=25-jun-1999 instead of F=1-jul-1999.
The F "cell centers" ought to default to the minimum TBOXLO of each forecast case.  The F "cell bounds" are undefined, and I'd suggest just assigning these bounds to sit midway between the cell centers, using whatever algorithm Ferret usually relies on when it sees an axis with no "bounds" attribute.  A user could then always regrid the F-axis to something else (e.g. the 1-month-wide strips you see above) using @bin.
In short, there are two well-defined and completely independent calendar axes: (1) the axis of start times F, defined using cell centers; and (2) the axis of verification times, defined as an inter-forecast union of T bounds (for time-averaged diagnostics like monthly-means) or T centers (for instantaneous snapshots).  The "diagonal plot" at top-right (if the strips were infinitesimally thin in the vertical) would be the fundamental representation of the forecast data -- always well-defined and accurate.
Then for convenience, we also have a constructed, fudged time axis of "approximate elapsed times".  This assumes that all forecast cases have "roughly similar" elapsed times (e.g. 1 month spacing), so that the "inter-forecast average" elapsed times will reasonably approximate any individual forecast's true elapsed times.


Fix earn push notifications

Fixes https://github.com/stackernews/stacker.news/pull/530#discussion_r1346794363
Changes

instead of sending one push notification per type (which then replaces all previous push notifications with tag EARN), the data is aggregated and then a single push notification for all types is sent
replaced async/await usage with forEach to for ... of

Tested this manually with some mock data:
diff --git a/worker/earn.js b/worker/earn.js
index b0f00fd..73c926c 100644
--- a/worker/earn.js
+++ b/worker/earn.js
@@ -13,6 +13,62 @@ export function earn ({ models }) {
   return async function ({ name }) {
     console.log('running', name)

+    const now = new Date(new Date().getTime())
+    const sum = 1e8
+    let total = 0
+    let earners = [
+      {
+        userId: 14912,
+        proportion: 0.041,
+        rank: 21,
+        type: 'POST'
+      },
+      {
+        userId: 14912,
+        proportion: 0.11,
+        rank: 3,
+        type: 'COMMENT'
+      },
+      {
+        userId: 14912,
+        proportion: 0.021,
+        rank: 32,
+        type: 'TIP_POST'
+      },
+      {
+        userId: 14912,
+        proportion: 0.041,
+        rank: 13,
+        type: 'TIP_COMMENT'
+      }
+    ]
+    const notifications = {}
+    for (const earner of earners) {
+      const earnings = Math.floor(parseFloat(earner.proportion) * sum)
+      total += earnings
+      if (total > sum) {
+        console.log(name, 'total exceeds sum', total, '>', sum)
+        return
+      }
+
+      console.log('stacker', earner.userId, 'earned', earnings, 'proportion', earner.proportion, 'rank', earner.rank, 'type', earner.type)
+
+      if (earnings > 0) {
+        await serialize(models,
+          models.$executeRaw`SELECT earn(${earner.userId}::INTEGER, ${earnings},
+          ${now}::timestamp without time zone, ${earner.type}::"EarnType", ${earner.id}::INTEGER, ${earner.rank}::INTEGER)`)
+        notifications[earner.userId] = {
+          ...notifications[earner.userId],
+          total: earnings + (notifications[earner.userId]?.total || 0),
+          [earner.type]: { msats: earnings, rank: earner.rank }
+        }
+      }
+    }
+
+    Promise.allSettled(Object.entries(notifications).map(([userId, earnings]) =>
+      sendUserNotification(parseInt(userId, 10), buildUserNotification(earnings))
+    )).catch(console.error)
+
     // compute how much sn earned today
     const [{ sum: sumDecimal }] = await models.$queryRaw`
       SELECT coalesce(sum(msats), 0) as sum
@@ -54,7 +110,7 @@ export function earn ({ models }) {
       return
     }

-    const sum = Number(sumDecimal)
+    // const sum = Number(sumDecimal)
     const heads = Math.random() < 0.5
     // if this category is selected, double its proportion
     // if it isn't select, zero its proportion
@@ -77,7 +133,7 @@ export function earn ({ models }) {
     */

     // get earners { userId, id, type, rank, proportion }
-    const earners = await models.$queryRaw`
+    earners = await models.$queryRaw`
       -- get top 21% of posts and comments
       WITH item_ratios AS (
           SELECT *,
@@ -140,37 +196,10 @@ export function earn ({ models }) {

     // in order to group earnings for users we use the same createdAt time for
     // all earnings
-    const now = new Date(new Date().getTime())
+    // const now = new Date(new Date().getTime())

     // this is just a sanity check because it seems like a good idea
-    let total = 0
-
-    const notifications = {}
-    for (const earner of earners) {
-      const earnings = Math.floor(parseFloat(earner.proportion) * sum)
-      total += earnings
-      if (total > sum) {
-        console.log(name, 'total exceeds sum', total, '>', sum)
-        return
-      }
-
-      console.log('stacker', earner.userId, 'earned', earnings, 'proportion', earner.proportion, 'rank', earner.rank, 'type', earner.type)
-
-      if (earnings > 0) {
-        await serialize(models,
-          models.$executeRaw`SELECT earn(${earner.userId}::INTEGER, ${earnings},
-          ${now}::timestamp without time zone, ${earner.type}::"EarnType", ${earner.id}::INTEGER, ${earner.rank}::INTEGER)`)
-        notifications[earner.userId] = {
-          ...notifications[earner.userId],
-          total: earnings + (notifications[earner.userId]?.total || 0),
-          [earner.type]: { msats: earnings, rank: earner.rank }
-        }
-      }
-    }
-
-    Promise.allSettled(Object.entries(notifications).map(([userId, earnings]) =>
-      sendUserNotification(parseInt(userId, 10), buildUserNotification(earnings))
-    )).catch(console.error)
+    // const total = 0

     console.log('done', name)
   }

just fyi another way to mock is to use the scrubbed DB I sent you and fast-forward all the items/itemacts by incrementing the createdAt times


Analyze prebuilts for fsharp

The following prebuilt packages are included as dependencies in source-build by fsharp.  These need to be analyzed to determine how to avoid requiring packages that source-build doesn’t build.

Change to use the source-built version
Package is not critical to product and can be removed.  (i.e.test-specific, windows-specific, etc)
The package is used as reference only
The package should be built in source-build
Other – please elaborate on what you think should be done.

For more detailed usage information for these, please see the Usage Exploration tab of the SourceBuildPrebuiltReport.
Prebuilt Status Updated 2019-06-24
Up to date prebuilt status can now be found in the SourceBuildPrebuiltReport in the Repo Status Data tab.
Prebuilt Table Updated 2019-06-24

PackageName
PackageVersion
SourceBuiltVersion
Category

FSharp.Core
4.6.2

Exclude from source build

System.Collections.Immutable
1.5.0

Ref-only

System.Reflection.Metadata
1.6.0

Ref-only

System.Runtime.Loader
4.3.0

Ref-only

Original Prebuilt Table

PackageName
PackageVersion
SourceBuiltVersion
Category

FSharp.Core
4.5.2

Microsoft.Win32.Registry
4.3.0

Pdb2Pdb
1.1.0-beta1-63314-01

System.Collections.Immutable
1.4.0

System.Data.SqlClient
4.3.0

System.Diagnostics.Process
4.3.0

System.Diagnostics.TraceSource
4.3.0

System.Linq.Expressions
4.3.0

System.Linq.Queryable
4.3.0

System.Net.Requests
4.3.0

System.Net.Security
4.3.0

System.Reflection.Emit
4.3.0

System.Reflection.Metadata
1.5.0

System.Reflection.TypeExtensions
4.3.0

System.Runtime.InteropServices
4.3.0

System.Runtime.Loader
4.3.0

System.Runtime
4.3.0

System.Security.Claims
4.3.0

System.Security.Cryptography.Algorithms
4.3.0

System.Security.Principal
4.3.0

System.Threading.Tasks.Parallel
4.3.0

System.Threading.ThreadPool
4.3.0

System.Threading.Thread
4.3.0

System.ValueTuple
4.4.0

XliffTasks
0.2.0-beta-000081
0.2.0-beta-000048

Updated table from SourceBuildPrebuildReport as of 5/31/2019:

PackageName
PackageVersion
SourceBuiltVersion
Category

System.Runtime.Loader
4.3.0

3

System.Reflection.Metadata
1.6.0

3

System.Collections.Immutable
1.5.0

3

FSharp.Core
4.5.2

Filed issue dotnet/fsharp#6912

All prebuilts removed.


Update my details in Community.md (Animesh Sahu)

Fixes #186
Updated my details in Community.md file.
Thanks!

Rebased on tip of the upstream main branch, resolving conflicts due to previous pr merges.


🐛 BUG: Markdown Syntax Issue

Folks 👋
There's a markdown syntax issue with a missing ) for the job [Cloud Ops Advocate | USA Mountain View](https://careers.microsoft.com/us/en/job/454630/Cloud-Ops-Advocate.
I hope it helps.
Peace! ✌

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

ID: 94615642-7eb7-83dd-52f1-ef6b78c687cf
Version Independent ID: 69e13745-a61d-9309-96b8-c102d01a70ec
Content: Join our team and make the world better for developers!
Content Source: teamblog/awesome-jobs.md
Product: team-blog
GitHub Login: @jeffsand
Microsoft Alias: jeffsand

Should be fixed now, thanks for the feedback @ahmadawais!

@dend it is. Glad to help. Peace! ✌


Can you share the prompt to query ChatGPT on WTQ?

Hi there,
Thanks a lot for your amazing work.
As titled, just curious about how to make ChatGPT follow the parsable output format.

You can directly use the final prompt here.

OK Thanks, so for the baseline (direct prompting), you did not ask ChatGPT to do CoT?

Yes!


Links are not password-protected when accessed through Card layout

Describe the bug
In card layout, the whole feature of password-protection is not implemented.
To Reproduce
Steps to reproduce the behavior:

Go to 'Card Layout'.
See there is no lock/unlock icon for any link
Click 'Open' for any password-protected link.
Link opens up without prompting for password.

Expected behavior
Lock/Unlock icon should be shown and Password should be prompted for password-protected links in Card View.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Could you please assign this to me?

Hey @rahul1995 the password protection was added just yesterday monly for the list view but It has to be implemented for Card view too, If you think you want to contribute to that part please go ahead

@rahul1995

Hey @monizb Let me do this one too! Can you plz assign this to me? Thanks!

Hey @harshvats2000 sorry missed your comment, looks like this has been taken up already, do you mind looking at the other open PRs too? Thanks!

@monizb Can I increase width of the card as the lock icon doesn't have any room for it right now?

@monizb Can I increase width of the card as the lock icon doesn't have any room for it right now?

Yes sure @rahul1995 whatever looks good should be fine, but please make sure the icon changes based on protected or not like in the list view

Fixed with PR https://github.com/monizb/FireShort/pull/81


[MINOR] Make QuickstartUtil generate random timestamp instead of 0

Tips

Thank you very much for contributing to Apache Hudi.
Please review https://hudi.apache.org/contributing.html before opening a pull request.

What is the purpose of the pull request
Make QuickstartUtil generate random timestamp instead of 0
timestamp generated by QuickstartUtil is always 0, which is inconvenient to test TimestampBasedKeyGenerator
Brief change log
(for example:)

Modify AnnotationLocation checkstyle rule in checkstyle.xml

Verify this pull request
(Please pick either of the following options)
This pull request is a trivial rework / code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end.
Added HoodieClientWriteTest to verify the change.
Manually verified the change by running a job locally.

Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Codecov Report

Merging #2340 (67f95c9) into master (26cdc45) will decrease coverage by 41.94%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             master    #2340       +/-   ##
=============================================
- Coverage     52.35%   10.40%   -41.95%
+ Complexity     2631       48     -2583
=============================================
  Files           329       51      -278
  Lines         14808     1787    -13021
  Branches       1484      213     -1271
=============================================
- Hits           7752      186     -7566
+ Misses         6441     1588     -4853
+ Partials        615       13      -602

Flag
Coverage Δ
Complexity Δ

hudicli
?
?

hudiclient
?
?

hudicommon
?
?

hudihadoopmr
?
?

huditimelineservice
?
?

hudiutilities
10.40% <ø> (-59.71%)
0.00 <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.


'CARLAEnv' object has no attribute 'seed'

File /Carla/RNN/carla-agent/rl/agents/agents.py", line 70, in set_random_seed
self.env.seed(seed)
AttributeError: 'CARLAEnv' object has no attribute 'seed'

Hi, I guess the error is due to the newer versions of gym to have adopted a new API, and so old things have broken... Try to install version 0.22 or older: e.g. pip install gym==0.22.0


Extend thoth-loader to handle L'Harmattan OA import

Create a new loader for Thoth for bulk ingest of L'Harmattan OA book metadata from CSV.

[ ] Create metadata mapping from CSV fields to Thoth metadata fields
[ ] Create loader
[ ] Test ingest locally, check over created records, fix/iterate if required
[ ] Submit draft PR for loader
[ ] Make changes based on PR and resubmit
[ ] Run live import (including preparation e.g. backup of existing data if required)

@ja573 I had this as an issue for thoth, rather than thoth-loader, so that it could appear on the general Thoth project board https://github.com/thoth-pub/thoth/projects/1 that we're using for project management. Could we move it back to thoth, even though it's not strictly a Thoth issue?

Don't worry about that – we're going to start using the new version of projects, which supports handling issues from various repositories


Drop item on adjacent (sibling) list item instead of inserting into list?

Is there a way, or what would be the best approach to accomplishing this?
If you have two adjacent lists of items, and you drag an item from list 1 to an item in list 2 within a certain footprint size (of the drop on item) be able to drop the item onto the item instead of inserting it into the adjacent list.
Here is what I have, it's not quite there
## Allowed movements
accept: (sourceItemHandleScope, destSortableScope, destItemScope) ->

  if destItemScope
    rangeTop = destItemScope.element.offset().top
    rangeBottom = rangeTop + destItemScope.element.height()
    handleTop = sourceItemHandleScope.itemScope.element.parent().offset().top
    inRange = (rangeTop < handleTop and handleTop < rangeBottom)
    if inRange
      destSortableScope.element.find('li.as-sortable-placeholder').remove()
      return false

  true

An easier way to put it-- is there a way to make an item sortable (draggable) + droppable?

with the clone option this should be possible, hence closing this.


nixos/modules/virtualisation: fix oci-containers with docker

The empty attribute set is invalidly provided as service config and results in evaluation error.
Description of changes
Fixes error:
error: cannot coerce a set to a string

       at /nix/store/dzpw10w1g3f76sj8akm9h903z883wm1s-source/nixos/lib/systemd-lib.nix:76:62:

           75|     optional (attr ? ${name} && !elem attr.${name} values)
           76|       "Systemd ${group} field `${name}' cannot have value `${toString attr.${name}}'.";
             |                                                              ^
           77|

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

@ofborg test oci-containers.docker
@ofborg test oci-containers.podman

Thanks @Cynerd !


[18066] Monitor Service Documentation

This PR adds the proper documentation for Fast DDS feature/monitor-service/high-level-empty-api
This PR should be merged after the v2.11.x brach out is done!

Running Manual CI here:

Manual CI running here

Manual CI running here

Manual run here

I took into account the previous comments. But as I am refactoring the entire feature, I wont apply all of them

Manual run here

Manual run here

Leaving a question here:
Is it correct to merge this PR regardless of the feature/monitor-service/main branch in Fast DDS or should we wait ? I mean, the documentation will fail to build until we merge that branch in Fast DDS (bascially due to the API references).

Manual CI here

Leaving a question here: Is it correct to merge this PR regardless of the feature/monitor-service/main branch in Fast DDS or should we wait ? I mean, the documentation will fail to build until we merge that branch in Fast DDS (bascially due to the API references).

We will not merge till the feature is implemented and merged into Fast DDS master branch. In the mean time, just rename the branch of this PR to feature/monitor-service/main, and the PR builds will automagically use that Fast DDS branch


npm install issue

Hi,
I'm trying to use this module,  when used via npm install ngA11y version 1.0.0 is installed. And 'nga11yAnnounce' is not error-ing with "unknown provider" in controller
Error:  Unknown provider
Whereas, if i clone and build using github, it works perfectly fine.
https://www.npmjs.com/package/nga11y
There seems to be a mismatch in version, can the latest be released?
Also, can the master version number in package.json be incremented from npm registry.  currently , i see 0.0.0

I don't think this particular package is released in npm library, it is only available through 'bower'.
When you do npm search as below, you will see it is distributed by different user 'jacobharasimo' and not 'dequelabs'.

We are looking into this issue, thanks for bringing it to our attention.

@chandramuralis  The version released in npm(1.0.0) is old and not consistent with github latest.

The owner of that npm repository (who forked our project) is being painful. We are thinking about a publishing this under ng-a11y and have reserved that npm package. Any objections to that name change here?

I don't have any issue with that... but it might be little bit confusing for the users trying to install through npm or bower.

Give us a little time to sort it out; we'll be sure to let you all know the correct install process moving forward!

@chandramuralis the bower module name is already ng-a11y

True... It's perfect then.

We have published under the package name ng-a11y. You can now find releases here: https://www.npmjs.com/package/ng-a11y


Line Numbers do not show in the browser

With Debug v3.1.0, line numbers always point to the debug file browser.js (loading from node_modules/debug/src/browser.js)

I see some closed issues on this topic: https://github.com/visionmedia/debug/issues/105
Seeing the correct line numbers would be a very nice feature.
Also, thanks for the great work.

+1

The original issue was closed because there is no actionable fix, so unfortunately I'm going to have to do the same for this one. Maybe browsers will someday support a feature to skip over that line of the stack trace but at this time it is impossible.

@petahbred @chaoyangnz  You're welcome!


Add missing var declaration

Hello,
Just found another undeclared variable when bundling 0.3.2.
Will you want the changed dist files as well or do you compile them only at release time?
Thanks again for alasql !

Current coverage is 67.25% (diff: 100%)

Merging #764 into develop will not change coverage

@@            develop       #764   diff @@
==========================================
  Files             1          1
  Lines          9806       9806
  Methods        1029       1029
  Messages          0          0
  Branches       2927       2927
==========================================
  Hits           6595       6595
  Misses         3211       3211
  Partials          0          0

Powered by Codecov. Last update 639a8b9...2155326

Awesome - thanks :)


ci: upgrade pre-commit hooks versions

PR checklist

[ ] Tests written/updated
[ ] Changelog entry added in .changelog (we use unclog to manage our changelog)
[ ] Updated relevant documentation (docs/ or spec/) and code comments

Sorry, just noticed it is a wip, are you still going to submit changes to this @melekes ?

Sorry, just noticed it is a wip, are you still going to submit changes to this @melekes ?

yes


Line-of-sight structure-enhanced ray-tracing halos rendering for external convergence and shear

Line-of-Sight Structure-Enhanced Ray-Tracing Halos Rendering for External Convergence and Shear
Description:
This pull request introduces an enhancement to the ray-tracing halos rendering mechanism. It incorporates both large-scale structures using GLASS and small-scale structures via the halo mass function.
Key Features:

Line-of-Sight Structure Rendering: This implementation utilizes the SkyPy halo module for the line-of-sight structure. It's worth noting that the currently used SkyPy halo module has not been merged into the main SkyPy branch, hence we're temporarily making use of Skypy_halos_duplicate.
Ray-Tracing Computations: For a given sky area, this feature generates halos within the corresponding light cone. It then employs ray-tracing techniques to compute the distribution of convergence ( $\kappa_{ext}$ ) and shear ( $\gamma_{tot}$ ).
Negative Mass Sheet Option: Users have the flexibility to generate a negative mass sheet which can be used for kappa correction.
Demonstrative Notebook: A notebook has been added to provide a hands-on demonstration of this feature.

Next Steps:

Testing and Documentation:

Test Functions: Enhance and finalize the test functions to ensure the feature's robustness.
Notebook: Refine the notebook to provide clearer demonstrations and examples.
Documentation: Improve the documentation to ensure comprehensive understanding and ease of use for the users.

Incorporate $\kappa_{ext}$ Correction:

We aim to introduce a correction factor for $\kappa_{ext}$:

$$ 1 - \kappa_{ext} = \frac{(1-\kappa_d)(1-\kappa_s)}{1-\kappa_{ds}} $$
This will ensure a more accurate representation and calculation in our rendering mechanism.
Acknowledgements:

Guidance and assistance from: @sibirrer  .
Feedback and suggestions from: @ajshajib .
Additional help from: @nkhadka21 .

We kindly request a review of this feature, and are open to further feedback and suggestions.

Hi @ajshajib, I noticed that pre-commit is complaining for the lines with characters greater than 88. Should pre-commit bot fix this automatically? It seems like it is not fixing them.

2. Incorporate κext Correction

Yeah, as stated in the description. Incorporating $\kappa_{ext}$ correction is what need to be focused in next step.


windows:support focus events

JWM dispatches WindowFocusOn and WindowFocusOff events on Windows.
In addition, JWM checks if window exists before dispatching events to
avoid NPE.

Awesome! Thank you!


AMBARI-24462. ambari-server upgrade stuck with NPE (amagyar)

clone of #2043

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/3567/
Test PASSed.


How does the routing work?

The README.md is missign a section about routing, and how one fully example on how to use it all together routing -> controller -> view.

c1f8e31f8552925e5f65845fa01a8386e88866d9

Good


Multi-gpu compatibility: torch-summary for 'cuda:1' and so on

Models in GPU devices other than 'cuda:0' can be summarized after this edit.
An edit was made in the way the kwarg 'device' accepted values. Instead of only accepting string values, the current edit allows for torch.device objects and (legacy) integer values to be accepted.
summary(model, (1,28,28),device="cuda:2"
summary(model, (1,28,28),device=torch.device("cuda")

Alas, it looks like this is a dead GitHub project. This PR has been in for close to a year and half, but no cigar.
Therefore this can't be used during production runs which require control over the GPU on which the code runs.


Roll inject

Update inject version to attempt windows fix

cc @yjbanov

Can't merge :D

Lets try again


Align handling of resource names

Currently we use different names for resource names (e.g. vaultName as an inputParameter for the KeyVault bicep template instead of name).
To make the modules easier to use and align closer with the arm template reference we should update these inputs to use name instead.
This requires an update to the template itself as well as its documentation & parameter file

Searching with regex
resource\s*(.*)@(.*)'\s*(?!existing)\s*= \{
  name: (?!name)

Done


Refactor styling to be more readable

Pull Request Test Coverage Report for Build 229

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 52.239%

Totals

Change from base Build 224:
0.0%

Covered Lines:
31

Relevant Lines:
50

💛  - Coveralls


docs - basic usage step 4: Handling Events

If use the same code in step4: Handing Events Section i am getting the Following Error

if i changed the Header section to the following it is working
    headers={b':status': '200'},

I assume you're looking at this page? http://python-hyper.org/projects/h2/en/stable/basic-usage.html#step-4-handling-events
Yes, we seem to be using the deprecated method of passing headers as a dict -- should be a list of tuples. Will fix.

Found it:

We also create a stable version, if your project has any tagged releases. stable will be automatically kept up to date to point at your highest version.

Highest tagged version of hyper-h2 is 2.4.1, which doesn't include this docs fix.
Fix is to cut a new major release of hyper-h2, which will presumably include the shiny new docs fixes, or change the docs to point at latest, not stable – not sure what @Lukasa prefers.

I kinda hate having the docs point at latest: it causes the API docs to contain things that haven't been released yet. Ideally we'll resolve this by shipping a new release soon.


In the generated application rely on the default @SpringBootApplication scanBasePackages

Since we develop here micro-services, that should not be secret that one main class just with @SpringBootApplication does the entire trick around the target protocol-specific adapter (service).
Typically it is just a single @Configuration class.
I don't see reason to add extra @Import  in the generated main class, since we can just move the last one to the application package and rely on the @ComponentScan. Fully similar like we do in the apps tests.
It doesn't matter that we generate applications for different binders, we will use only one at runtime. So, the generate jar must have @SpringBootApplication on the top-level package to be able to pick up the app configs automatically without any extra manipulations for the generator config.
Plus we will be free with naming for app @Configurations.
Let me know what I have missed here around that led you to follow with the @Import solution.

@artembilan Initially we were using the auto configuration approach by providing spring.factories in all the starters. This turned out to be an issue for some applications as it would automatically bring in configuration thats not needed or give conflicts. We had to manually exclude those beans. To fix this issue, we disabled auto configuration completely in the starters and manually inject the @Import annotation in the generated application main class using the plugin. This way, the application won't get auto configured with the beans, but only if we provide the necessary import.
The above works using the plugin, but when we use start-scsapps for the same purpose, the users have to manually modify the main class to add that @Import.
Using @SpringBootApplication and making the application main class reside in the same package name as the @Configuration class has few issues as well.

The issues mentioned above would be manifested here again, i.e. since @SpringBootApplication does a component scan on the base package, it would do an auto configuration for the beans thus having the same problems as above.

We cannot really force the use of the same package used for @Configuration for the end user applications due to organizational restrictions and other reasons. If someone changes the package to a different one than whats used for the configuration, then using @SpringBootApplication for auto configuration won't work anyway since we don't provide spring.factories in the starters.

cc @markfisher - there were some issues we had with auto configuration which made us to switch to @Import.

The specific conflict we encountered was when building upon one of the starters as a library by embedding it and adding additional logic (e.g. transformation). In such a case, we don't want the binding to happen for the embedded app, but rather only for the composed app that includes that embedded app alongside additional functionality.

Thank you, guys, for feedback.
I didn't think about the Initializr when raised this issue and now I think that for global my concern doesn't matter, just because the generated app (via Initializr) may have any package for the top-level main with @SpringBootApplication.
My point was about out-of-the-box apps, when I have some naming restrictions for my app @Configuration class and should do some other steps to let generator to know about my classes. And not just rely on the built-in @ComponentScan from the @SpringBootApplication in the top-level package. Current kafka/rabbit structure eliminates that trick from Boot.
OK. Now have more info around I can live with these restrictions.
But on the other hand here are my additional five cents.
I don't understand the fear against auto-configuration. Just because all others are there anyway. For example I was surprised that SC-AWS auto-configure for me SES service when I need only S3.
That is a different story: nevermind :smile:
But from other side my main goal of the s3-source micro-service hasn't been reached. Just because my AmazonS3SourceConfiguration isn't visible by SpringApplication!
That's why I would like to see S3SourceRabbitApplication in the org.springframework.cloud.stream.app.s3.source package, not rabbit sub-package to let OOTB app to be as clear micro-service.
Backing to the auto-configuration fear, I'd say that something wrong and weird here around with the auto-configuration concepts, like it is in the Spring Boot. If you worry about some customization from the end-user application, you should apply to your autoconfigs all those possible useful @Conditional and really let end-user to rely on just the auto-configuration and override those beans which he needs. E.g. with the same S3 Source I would like to leave the S3InboundFileSynchronizer bean as is, but add localFilter to the S3InboundFileSynchronizingMessageSource bean overriding it. Right, the localFilter isn't supported in the AbstractRemoteFileSourceProperties.
Having the current state, I don't see how those OOTB @Configurations can be useful for custom app, independently of the fact of @ComponentScan or @Import.
Again I may miss something, so forgive me for ignorance. For this purpose I would like to see the code of that composed application, because it isn't clear for me how @EnableBinding can be skipped for the "embedded app".

For a custom app, @Configuration would only be useful if they import that configuration class using @Import.
By embedded app, I think Mark was referring to an aggregated app. In SCS, for aggregated apps, there is no binding takes place even if there is a binder on the class path. For instance, if I have an aggregated app like this - http | processor | gemfire (all bundled into a single app), there won't be any binding even if the backing http implementation is http-source-kafka.

@EnableBinding is not skipped for an embedded app, it is just that in the specific case when the aggregated chain begins with a source and ends with a sink, no channels will be bound (because all are directly bound between the applications). If the aggregated chain starts or ends with a processor, the starting input channel or ending output channel will be bound. Unfortunately, even if no channel is supposed to be bound, we do require the presence of a binder (which, by itself, is a bug).
Generally speaking, the issue with autoconfiguration here is that it prevents the libraries to be reused in a 'simple' fashion - e.g. only using the repositories in the analytics module Also, in aggregation scenarios we will not want the modules to be auto-imported at the root level, as aggregation relies on creating child contexts for each aggregated application (also for being able to set up configuration properties separately and to order them explicitly in the sequence).

The binder is not included in the aggregate applications anymore. @artembilan - if you've any specific issue that you'd like to bring up, please create a separate ticket in the release-train repo.


⚠ T:Riza Docs has degraded performance

In a8785bb, T:Riza Docs (https://docs.triza.dev) experienced degraded performance:

HTTP code: 200
Response time: 4982 ms

Resolved: T:Riza Docs performance has improved in 82eb7c5.


xsd:list not handled in code generation

Elements defined as lists are skipped over during code generation. For example Experiment/Type:
<xsd:attribute name="Type" use="optional">
  ...
  <xsd:simpleType>
    <xsd:list>
      <xsd:simpleType>
        <xsd:restriction base="xsd:string">
          <xsd:enumeration value="FP"/>
          <xsd:enumeration value="FRET"/>
          ...
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:list>
  </xsd:simpleType>
</xsd:attribute>

The generated code ends up with type = None for that field, and no corresponding enum is produced.
Schemas can define lists containing any type, but the OME schema only has two cases: Experiment/Type and MicrobeamManipulation/Type. I think we just need a little extra logic in Member to both detect these as lists (maybe in .max_occurs) and also extract the nested type for further processing (e.g. enum generation). These Type attributes are optional so they might not appear in a given document, but I think we should normalize that to an empty list in our model classes rather than make it Optional. xmlschema to_dict does return a list of strings for an xsd:list (if the attribute is present) so we don't need to do anything extra there.

question:  what is the syntax for an XML attribute that can be a list?
the only OME example I could find was this ... but xsd:list suggests thatExperiment can also have multiple Types, yes?
    <Experiment ID="Experiment:1" Type="TimeLapse">
        <Description>Cell Embryo</Description>
        <ExperimenterRef ID="Experimenter:1"/>
    </Experiment>

...sorry, stumbled upon the answer myself:  space delimited... eg:
    <Experiment ID="Experiment:1" Type="TimeLapse SpectralImaging">
        <Description>Cell Embryo</Description>
        <ExperimenterRef ID="Experimenter:1"/>
    </Experiment>


[material] Add variant prop type in all components

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
Creating a List component variant causes TypeScript errors when using the variant prop in the variants declaration or at the component usage site.
Suppressing the TypeScript errors allows the variant to be declared and used as expected.

Expected behavior 🤔
Creating a List component variant is supported in TypeScript.
ListProps should have a declaration for variant, like we have in ButtonProps:
    /**
     * The variant to use.
     * @default 'text'
     */
    variant?: OverridableStringUnion<
      'text' | 'outlined' | 'contained',
      ButtonPropsVariantOverrides
    >;

Steps to reproduce 🕹
Steps:

Create a component variant for List using TypeScript.

CodeSandbox
Context 🔦
We're maintaining a UI library built on top of MUI, and we want to provide a "bordered" List variant for our users. This is is blocking us from doing that.
Your environment 🌎
No response

The List component does not have a variant prop in it's API.

The List component does not have a variant prop in it's API.

Isn't that because your API docs are generated from typings?

I started to work on a PR for this.

@jussirantala Can you provide a CodeSandbox showing a List component is using a variant prop, and only that the type is missing? The issue template maybe a good starting point. Thanks.

Here you go: https://codesandbox.io/s/list-variant-bug-5fqdfp?file=/src/App.tsx

Thanks for the reproduction. Looks like a bug indeed.
Not sure how does the style (background: red) gets applied if there is no support of variant prop in the List component implementation.
Looks like this would be the case for many other components in general.

Seems it also complains about missing component prop if variant prop is used. I don't know the reason for that.

Hi guys, I have similar issue with FormHelperText -> https://github.com/mui/material-ui/issues/33564

Adding here some of the conversations we had on the open pull request. These are some open questions that would arise if we decide to support this in all components:

the component initially didn't supported the prop - this would mean that the component does not handle in anyway the prop, which would mean that it would be spreader on the inner DOM element. Should we always not propagate the prop in all components?
the component handles the prop, but the tree rendered depends on the variant prop - this means that we can't simply change it as we would break the internal logic of the component
what if this discussions gets created for a different prop next, like the size should we then handle this prop in all components too?

Hi @mnajdova,
Wondering if there is any progress on this? We assumed variants to be supported in all component as mentioned in the docs. Our designer put time and effort in creating variants, now this does not seem to be supported. I would at least expect something like a notice in the docs, we could have been aware of this months ago.

Hi @mnajdova,
Wondering if there is any progress on this? We assumed variants to be supported in all component as mentioned in the docs. Our designer put time and effort in creating variants, now this does not seem to be supported. I would at least expect something like a notice in the docs, then we could have been aware of this months ago.

Similar situation here, without the variant prop in List/ListItem/ListButtonItem, I am not able to implement my designer's variants the way we we implement new variants to other components like Button or Typography.

Hi @mnajdova,
Wondering if there is any progress on this? We assumed variants to be supported in all component as mentioned in the docs. Our designer put time and effort in creating variants, now this does not seem to be supported. I would at least expect something like a notice in the docs, then we could have been aware of this months ago.

Similar situation here, without the variant prop in List/ListItem/ListButtonItem, I am not able to implement my designer's variants the way we we implement new variants to other components like Button or Typography.

Actually, I learned that you can add your own variant prop  (or any other custom prop) via the OwnProps interfaces. For example:
/* eslint-disable @typescript-eslint/no-empty-interface */

export type CustomListItemButtonOwnProps = {
  variant?: "standard" | "condensed" | "comfort";
  otherCustomProp?: boolean;
};

declare module "@mui/material/ListItemButton" {
  interface ListItemButtonOwnProps extends CustomListItemButtonOwnProps {}
}

or just
declare module "@mui/material/ListItemButton" {
  interface ListItemButtonOwnProps {
    variant?: "standard" | "condensed" | "comfort";
    otherCustomProp?: boolean;
  }
}

Hi @mnajdova,
Wondering if there is any progress on this? We assumed variants to be supported in all component as mentioned in the docs. Our designer put time and effort in creating variants, now this does not seem to be supported. I would at least expect something like a notice in the docs, then we could have been aware of this months ago.

Similar situation here, without the variant prop in List/ListItem/ListButtonItem, I am not able to implement my designer's variants the way we we implement new variants to other components like Button or Typography.

Actually, I learned that you can add your own variant prop (or any other custom prop) via the OwnProps interfaces. For example:
/* eslint-disable @typescript-eslint/no-empty-interface */

export type CustomListItemButtonOwnProps = {
  variant?: "standard" | "condensed" | "comfort";
  otherCustomProp?: boolean;
};

declare module "@mui/material/ListItemButton" {
  interface ListItemButtonOwnProps extends CustomListItemButtonOwnProps {}
}

or just
declare module "@mui/material/ListItemButton" {
  interface ListItemButtonOwnProps {
    variant?: "standard" | "condensed" | "comfort";
    otherCustomProp?: boolean;
  }
}

Yes you can extend the props or find other ways to create variants. But the variant functionality, so using variant in the theme, that is described in the docs of MUI, will not work. This means we have different ways of adding variants, which is not really desirable.


Getting AttributeError while running StartBark.bat on Windows 11

Traceback (most recent call last):
File "C:\projects\bark-gui\webui.py", line 295, in
gr.Markdown(f"### {APPTITLE}")
File "C:\Python39\lib\site-packages\gradio\components.py", line 5931, in init
IOComponent.init(
File "C:\Python39\lib\site-packages\gradio\components.py", line 215, in init
else self.postprocess(initial_value)
File "C:\Python39\lib\site-packages\gradio\components.py", line 5950, in postprocess
return self.md.render(unindented_y)
File "C:\Python39\lib\site-packages\markdown_it\main.py", line 267, in render
return self.renderer.render(self.parse(src, env), self.options, env)
File "C:\Python39\lib\site-packages\markdown_it\main.py", line 252, in parse
self.core.process(state)
File "C:\Python39\lib\site-packages\markdown_it\parser_core.py", line 32, in process
rule(state)
File "C:\Python39\lib\site-packages\markdown_it\rules_core\linkify.py", line 30, in linkify
raise ModuleNotFoundError("Linkify enabled but not installed.")
ModuleNotFoundError: Linkify enabled but not installed.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\projects\bark-gui\webui.py", line 408, in
barkgui.close()
File "C:\Python39\lib\site-packages\gradio\blocks.py", line 1389, in exit
self.config = self.get_config_file()
File "C:\Python39\lib\site-packages\gradio\blocks.py", line 1356, in get_config_file
props = block.get_config() if hasattr(block, "get_config") else {}
File "C:\Python39\lib\site-packages\gradio\components.py", line 5954, in get_config
"value": self.value,
AttributeError: 'Markdown' object has no attribute 'value'

Your version of gradio seems to be dependant on the linkify module. I've included this in the requirements since then but in case you don't want to upgrade a

pip install linkify
should fix this.


Protocol 'WebSocket' as a type cannot conform to 'Equatable'

You are likely trying to put a WebSocket in a Dictionary. Unfortunately that isn't possible and that will result in the compiler error that you mentioned in the title. At some point I might refactor WebSocket to make that easier, but until then I recommend wrapping the WebSocket in a struct or class. You can give that object a unique identifier and make it support Equatable / Hashable


[19.09] opencv3: 3.4.7 -> 3.4.8, addressing CVE-2019-14491, CVE-2019-14492 & CVE-2019-15939

This is a backport of https://github.com/NixOS/nixpkgs/pull/72625.
Closes https://github.com/NixOS/nixpkgs/issues/70117.

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

Notify maintainers
cc @mdaiter @basvandijk

@GrahamcOfBorg build opencv3

Fixed by: https://github.com/NixOS/nixpkgs/pull/72993


Ball texture

Need texture for the soccer ball.

Added a new object "Blueball", and assigned materials to the object.


Bump arrayvec to 0.7

tl;dr they released arrayvec 0.6.1 making new a const fn, but that led to performance regressions so they reverted it, which was a breaking change.

Coverage decreased (-0.4%) to 83.222% when pulling bb6fa8ebcc3844fcd72b076cb9c3ba586e2e4ddf on shssoichiro:arrayvec-0.7 into 00a0fb300032a441988d50b1ddea62bdc3cef821 on xiph:master.


More refactoring of SearchGroup

This PR continues the work started in #260. It refactors SearchGroup to provide a more appropriate API that handles user initiated search and substitution. SearchGroup maintains (global) state and highlights results. The SearchHelper class is intended as a lower level API that does not require state, and is an appropriate API to use from extensions.
This PR will:

[x] Remove unnecessary APIs from SearchGroup and update usages to use SearchHelper or other appropriate APIs.
[x] Remove CommandFlags.FLAG_SEARCH_FWD and FLAG_SEARCH_REV. The commands simply pass direction into the SearchGroup APIs
[x] Fixes bugs with last used search or substitution patterns. Various bugs with updating the correct pattern at the correct time, and using the correct pattern. Behaviour matches Vim, with added tests
[x] Fixes to the multiple-cursors extension to use the appropriate search APIs that don't interact with state or highlights. Also fixes a few issues with compatibility with the Vim plugin:

Matches no longer update state
Search highlighting is not updated for the matched occurrences, and stays at last search/substitute pattern
Searches are now always case sensitive, like the plugin
Asterisks, etc. in selected text are no longer treated as regex wildcards
"Select all occurrences" works correctly with 'nowrapscan', so only finds to the end of the file
"Select next occurrence" from an existing selection no longer uses word boundary flags
Show "no more matches" at correct time

[x] Update tests

Matt, I've rebased your PR on the latest master and found several things:

CommandParser.java was transferred to kotlin, so it's now CommandParser.kt, so I've updated this class in the latest commit.
One of your previous tests fails with this PR. Exactly because of changes in CommandParser. Could you please check it? test goto line with scrolloff


[BUG] ArgoCDProp credential type 'TOKEN' results in app sync error

Describe the bug
When selecting TOKEN as the credential type to access git for ArgoCD Workloads repo, the applications do not sync, citing an "invalid auth" error.
To Reproduce
Steps to reproduce the behavior:

Using the bootstrapping example described here, users can provide credentials for git access using credentialsSecretName (provided using SecretsManager) and credentialsType.
While TOKEN is available as a credential type, and with the appropriate Github access token stored in Secrets Manager under the name credentialsSecretName, using it results in app sync error on ArgoCD.

Expected behavior
The apps to be synced successfully on Argo.

TOKEN was not stored correctly. Closing the issue.


Fetch runs every ten seconds, update tests.

This PR just adds an interval of 10 seconds for fetching runs on the DataPackPage. Also updated the unit tests

Coverage decreased (-0.009%) to 81.881% when pulling 60accd6f1d80feff4c20c07d27e94d43a7c6398f on 21046-FetchRunsAtInterval into 5fce84384ab8bf74c650c29d9d36a557928b6c28 on master.

Coverage increased (+0.02%) to 81.909% when pulling 492a835b2e3301e40606bcbd09a71b4633e7ce74 on 21046-FetchRunsAtInterval into 5fce84384ab8bf74c650c29d9d36a557928b6c28 on master.

Coverage increased (+0.02%) to 81.947% when pulling 074ee904189a0aaa7972631c37789126ed897027 on 21046-FetchRunsAtInterval into 122bff01c365a7f84c56d3bcd346d1e0edf25615 on master.

Coverage increased (+0.02%) to 81.216% when pulling 285cc3019baca5eb2c4df2ec4d273bcbf8d979cb on 21046-FetchRunsAtInterval into 11cc12240098fd6d693e33565ab3ac7d4220c608 on master.


What is the purpose or intent of the web-ui?

Is the web-ui project intended to plug into a database via an adapter to provide a policy interface or is it just an example of how someone might provide a ui for a Casbin data store?
If you can provide clarification here I can open a pull request against README.md to clarify.

I want it to be the official web UI for Casbin, so people can view, add, remove policy rules for their enforcer. But currently it cannot fully serve that purpose yet..

@hsluoyz ahh gotcha. Looking at some of the code it looks like the interfaces read/write to files in the filesystem. Is there a plan to support using adapters? I'm looking at a way to get a ui into the database stored policies in my system.

Yeah. We want to support DB. Can you make a PR for it?

@hsluoyz it might overlap with some work I'm looking at doing. I'm trying to figure out if there is a better approach. Something like using Casbin-server to expose a restful-api and then casbin-ui to consume it like:
Casbin-server <-> casbin-ui
In my case I'll probably build directly against Casbin with my golang application, using Gorm-adapter, and thank you for updating that, but it doesn't make sense for me to add a new api for casbin-ui if I could use Casbin-server to host that.
Thoughts?

@chmorgan I think you are correct. We can improve Casbin-UI to make it consume RESTful API of Casbin-Server. Can you help it?

@hsluoyz I might be aligned to do so in the near future and will be sure to submit some pull requests when I arrive back to my casbin integration work.

Thanks !