[MODFISTO-240] Allowing to unrelease expended encumbrance

Purpose
MODFISTO-240 It should be possible to unrelease expended encumbrance
Approach

Undid the changes in MODFISTO-233 that prevented to unrelease expended encumbrance, and removed the related unit test.
Changed the calculation of the amount for an unreleased encumbrance, taking into account the expended amount and the amount awaiting payment, and updated the related unit test.

Pre-Merge Checklist
Before merging this PR, please go through the following list and take appropriate actions.

Does this PR meet or exceed the expected quality standards?

[ ] Code coverage on new code is 80% or greater
[ ] Duplications on new code is 3% or less
[ ] There are no major code smells or security issues

Does this introduce breaking changes?

[ ] Were any API paths or methods changed, added or removed?
[ ] Were there any schema changes?
[ ] Did any of the interface versions change?
[ ] Were permissions changed, added, or removed?
[ ] Are there new interface dependencies?
[ ] There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

What other modules will these changes impact?
Do JIRAs exist to update the impacted modules?

[ ] If not, please create them
[ ] Do they contain the appropriate level of detail?  Which endpoints/schemas changed, etc.
[ ] Do they have all they appropriate links to blocked/related issues?

Are the JIRAs under active development?

[ ] If not, contact the project's PO and make sure they're aware of the urgency.

Do PRs exist for these changes?

[ ] If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment.  Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.
While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.

checkOrderReEncumberWorksCorrectly() fails randomly but this is not related.

The integration test was moved to cross-modules.


More React-like composing API?

I wonder what Reactabular would look like if all the DOM-related configuration was done via components.
Formatters
the column and header formatters are almost the same signature as React function components. They could instead accept all the parameters as props, and composition would be done via the children prop. Let's call such a component a  View.
const colorColumn  = {
 property: 'color',
 Views: [({value}) => <ColorBox color={value}/>],
}
// ...later, we want to add a popup when you click the cell
const colorPickerPopup = ({value, rowData, children}) => (

 openPicker(rowData)}>{children}

)
// can also be done with column extensions
colorColumn.Views.unshift(ColorPickerPopup)

Search input
Allow configuring the search by providing components that adhere to value, onChange(), except that onChange can be called with newValue directly instead of through a synthetic event (it's not easy to generate those and not really necessary either).
A column could have a SearchInput prop that is used for that particular column. Then it is really simple to provide a ternary input for Booleans, a select input for enums etc, when using searchtabular.Field and searchtabular.Columns.
Inline editing
An inline editor column extension could key off editable: true and inject a View that switches the cell to edit mode on click, using a component given as an Input prop, calling an onRowChange(row, property, value) callback that is provided to the table.
Row rendering
instead of the onRow(row, extra) function that adds properties to some component, accept a Row component that gets the same information via props and has to return a
 (because of html) that somehow incorporates the given children.
This one is a bit debatable, because wrapping it for adding functionality means having to clone the
 since you can't have anything but
 under
. Not sure if that is a huge performance issue though.
Final thoughts
These API changes could be non-breaking, e.g. formatters could be run first and their result passed to Views as children.
Also, note that all the other functionality of Reactabular stays untouched due to it not being involved in these code paths; long live composition :)

Formatters

the column and header formatters are almost the same signature as React function components. They could instead accept all the parameters as props, and composition would be done via the children prop. Let's call such a component a View.

The old API was more of a convenience choice as often you are only interested in value, but going with an object would allow you to plug React components in without any problems so this could be a worthwhile change.
Instead of [(, { rowData: , column: <column>, columnIndex: <number> })] we would do just { label: <string>, rowData: <data>, column: <column>, columnIndex: <number> }].
Search Input

A column could have a SearchInput prop that is used for that particular column. Then it is really simple to provide a ternary input for Booleans, a select input for enums etc, when using searchtabular.Field and searchtabular.Columns.

This might need more examples. I kept the core decoupled from concerns like search on purpose while having the minimum amount of props. Maybe it would be better to try to build on top of the core and explore ideas like column extensions here?
Inline Editing

An inline editor column extension could key off editable: true and inject a View that switches the cell to edit mode on click, using a component given as an Input prop, calling an onRowChange(row, property, value) callback that is provided to the table.

Yeah, this is a good place for a column extension. No need to burden the core.
Row rendering

instead of the onRow(row, extra) function that adds properties to some component, accept a Row component that gets the same information via props and has to return a  (because of html) that somehow incorporates the given children.
This one is a bit debatable, because wrapping it for adding functionality means having to clone the  since you can't have anything but  under . Not sure if that is a huge performance issue though.

onRow is a sore point of the current design and I don't like it very much. It was a necessity as I needed some way to intercept per row. My main problem with it is that it doesn't feel declarative.
Maybe the proper solution would be to scratch onRow and follow the components prop idea instead? I imagine we could do
and drop the prop. This would be a minor change (backwards compatible).
Going through components would skip the wrapping problem since you would essentially replace rows entirely. I think this should allow composition too so you could compose a row through the same interface.
Final thoughts

These API changes could be non-breaking, e.g. formatters could be run first and their result passed to Views as children.

Overall the changes seem pretty minor. Pushing formatters a notch further and eliminating onRow in favor of component based composition would feel like the most immediate wins to me. Perhaps the rest could be solved by building on top of the core (i.e., column extensions).

Formatters

Instead of [(, { rowData: , column: <column>, columnIndex: <number> })] we would do just [{ label: <string>, rowData: <data>, column: <column>, columnIndex: <number> }].

Right, except that I would rename label to value so display components could be reused between headers and rows (academic maybe).
What are your thoughts on the attribute name Views with a capital letter to indicate components? It would also allow keeping formatters as-is for backwards compatibility.
Search
Yes, for me search is already decoupled, and I was proposing how to pass props that can be used by the column extensions.
It would be nice to have a diagram of the data flow in Reactabular. Something like, raw rows and a columns definition goes in, and then there is a transformation of the columns definition depending on what extensions you are using, and a transformation and filtering of the row data, before going into the table components that present the converted rows using the components defined in the columns.
Row rendering
Yes, I'd love it if you can specify your own Row/Cell renderer, and in fact I think it would be nice if those were direct props on Provider, Body and Header.
Final thoughts

Overall the changes seem pretty minor. Pushing formatters a notch further and eliminating onRow in favor of component based composition would feel like the most immediate wins to me. Perhaps the rest could be solved by building on top of the core (i.e., column extensions).

That was my feeling too, it's little corners in the API that grate a little bit, for the rest things are really nice.

Formatters

Right, except that I would rename label to value so display components could be reused between headers and rows (academic maybe).

Makes sense. It's a better name. That label came from header, but going with value is nicer for sure.

What are your thoughts on the attribute name Views with a capital letter to indicate components? It would also allow keeping formatters as-is for backwards compatibility.

Even though it's a little painful for the users (not that many fortunately 👍), I would revamp formatters to the new scheme. Smaller API surface.
It would mean react-edit would need a major version bump, but overall this feels like a good change to make.
Search

Yes, for me search is already decoupled, and I was proposing how to pass props that can be used by the column extensions.

I think I'm going to need a little code example to see the light with this one.

It would be nice to have a diagram of the data flow in Reactabular. Something like, raw rows and a columns definition goes in, and then there is a transformation of the columns definition depending on what extensions you are using, and a transformation and filtering of the row data, before going into the table components that present the converted rows using the components defined in the columns.

I could draw one if that helps. Some of the processing is arbitrary and it depends entirely on the use case, but the internals are well specified.
Row rendering

Yes, I'd love it if you can specify your own Row/Cell renderer, and in fact I think it would be nice if those were direct props on Provider, Body and Header.

Ok, I would go with the components idea here. If you could set
 that might be enough and allow us to ditch onRow once and for all. This definition would override Provider one should it exist. It's not a difficult addition to make.

So how about the following core API ([] denoting optionals):

reactabular-table components:

<Provider [Table] [Row] [HeaderCell] [Cell] columns={...} [...tableProps]>[children]</Provider>

column definition: as before, but with additional Views that generates the children of Cell

Other things I noticed:

Provider injects the columns into context, and Header uses it, but search.columns doesn't use it…
extensions exposes bind which overrides the default Function.bind. Would a better name be compose?
Would it not make more sense to put resizeable etc on the column and not on column.header? The whole column is resizeable even though the UI lives in the Header…

reactabular-table components: ...

Looks good to me.

column definition: as before, but with additional Views that generates the children of Cell

I'm not sure about this. formatters effectively does this so I would merge the idea there to keep the API slim.

Provider injects the columns into context, and Header uses it, but search.columns doesn't use it…

Correct. One option would be to drop the context entirely. Less complexity although then you have to do more wiring yourself. That said, you could still implement the context idea on top of a lower level API like this.

extensions exposes bind which overrides the default Function.bind. Would a better name be compose?

That could very well work.

Would it not make more sense to put resizeable etc on the column and not on column.header? The whole column is resizeable even though the UI lives in the Header…

This has to do with the original design (no sticky header/body yet). The point was that width changes made to a header would cause body to resize as well. The design could change for sure.
When it comes to sticky and width syncing, I tried a simpler alternative in which the table captured the widths through event bubbling, but for some reason this killed the performance although the syntax was a lot nicer.

I just thought of an issue: When you need to externally influence the rendering, you can't create new components, since that would cause the existing elements to be unmounted. You have to use props.
So table components can be custom for each table, but they should remain the same components for the lifetime of the table.
Therefore, the Table should accept extra props that it passes on to custom components.
To prevent unnecessary rerenders, the props should be granular, e.g. only for the HeaderCell or RowCell of column; for dev comfort, the props should also be general if required.
So something like a tableProps={{sharedProp}} columnProps={[null, null, {header: {...}, row: {...}}, null]} perhaps?
By passing props instead of a prop-returning function, it also makes figuring out when to update cells easier, just rely on the props.

Could those extra props be passed through the column definition? That's what the current design does more or less if I understood right.

Hmmm right, I tried that (I have a wrapper that sort of implements this) and it works but it means messing with the columns definition in the render cycle, which is a little annoying and ugly…

That could be a design smell. One option would be to try to push props to a definition of their own.

Yes, with props separate from columns, only the affected cells will be re-rendered.
how about headerProps and rowProps being arrays like the columns, e.g. the second header column gets the second item from headerProps merged into its props?
 That would not be needed if the columns have a propKey property which selects the subsection of headerProps/rowProps they get…

how about headerProps and rowProps being arrays like the columns, e.g. the second header column gets the second item from headerProps merged into its props?

Given there's columns, we could mimic the design and do props while mimicking the same shape. That gives easy shared props between header/cells while keeping the design similar to the old.
If the idea of maintaining a context is dropped, both could be split further and you would end up with
 and such.

 That would not be needed if the columns have a propKey property which selects the subsection of headerProps/rowProps they get…

Yeah, unless you fork the data after filtering. That was the idea I was getting at in the previous paragraph. We can manipulate the data close to the old way while being more explicit about how we pass it to React. That feels like a good compromise here.

On Mon, Feb 6, 2017 at 4:06 PM Juho Vepsäläinen<EMAIL_ADDRESS>wrote:

how about headerProps and rowProps being arrays like the columns, e.g. the
second header column gets the second item from headerProps merged into its
props?
Given there's columns, we could mimic the design and do props while
mimicking the same shape. That gives easy shared props between header/cells
while keeping the design similar to the old.

Yes, but header cells and row cells don't need the same data, so you'd be
updating all the rows if only the header needs changing. May not be a real
issue in practice though. I'd call them columnProps then?
If the idea of maintaining a context is dropped, both could be split

further and you would end up with

and such.

Hmm, I kinda like the context… How much extra "boilerplate" would that mean
for general Table use?
 That would not be needed if the
columns have a propKey property which selects the subsection of
headerProps/rowProps they get…
Yeah, unless you fork the data after filtering. That was the idea I was
getting at in the previous paragraph. We can manipulate the data close to
the old way while being more explicit about how we pass it to React. That
feels like a good compromise here.

I don't understand, the hidden columns still need to be removed from the
columns given to the table, no? So the same thing needs to be done to
props? (columnProps)

Yes, but header cells and row cells don't need the same data, so you'd be
updating all the rows if only the header needs changing. May not be a real
issue in practice though. I'd call them columnProps then?

That's a good point. In a more granular design scu should kick in. Granular checks are easier to make.

Hmm, I kinda like the context… How much extra "boilerplate" would that mean
for general Table use?

Any header/body would need its definitions through props.

I don't understand, the hidden columns still need to be removed from the
columns given to the table, no? So the same thing needs to be done to
props? (columnProps)

That's a great point. It's a syncing problem. One way to solve that would be to extract the concept of order and treat props/columns as objects. The third concept would unify these so you would get ['id', 'name'] kind of an array that would map to those object keys. To hide columns or re-order it, you would manipulate this particular structure.

I don't understand, the hidden columns still need to be removed from the columns given to the table, no? So the same thing needs to be done to props? (columnProps)

That's a great point. It's a syncing problem. One way to solve that would be to extract the concept of order and treat props/columns as objects. The third concept would unify these so you would get ['id', 'name'] kind of an array that would map to those object keys. To hide columns or re-order it, you would manipulate this particular structure.

Yes, that would be much nicer, plus you'd have a key for the column cells in a row, so that moving or hiding columns doesn't result in a bunch of re-renders. Sorting state could also be stored in that latter structure.

Ok I will summarize the proposed changes here, updating this comment if needed. I'll assume no context, to see where we get. I'm going to assume API breakage, choosing nice names, and perhaps we can add backwards compatibility to that.
General ideas

We remove context and pass things explicitly
We avoid rendering functions, instead using React components, so React can optimize re-rendering according to props

As a consequence, additional props for those components need to be passable.

This object is always named props or <component>Props in case of multiple components.
When passing props for columns, they go in a keyed-by-column-id object propsByCol

React components (even if functional) are passed as Capitalized arguments, out of convention and because they can then be used without renaming in JSX.
All columns definitions have an id to be able to refer to them even when hidden or reordered
Data rows are wrapped in getter objects that point to the original data and have a getter for each column id and the original index.

The getter class is generated from the columns and changed as little as possible so the VM can optimize it
(if the column ids are exactly row data attributes, and there is no need to know the original data index, wrapping is not needed)

columns
This is an array of definitions:
[{
   id, // unique
   getValue: obj => ..., // optional, only needed if value is not rowData[id]
   header: {views: [{Cell, props}], cellWrap = 'th', wrapProps, ...},
   body: {views: [{Cell, props}], cellWrap = 'td', wrapProps, ...},
   ...
}]

The Cells and props will generally be the result of wrapping from column extensions. The id is used to refer to the columns and to retrieve the value from rowData.
views is an array of Cell components with optional props, which is rendered with
cellProps => views.reduce((children, {Cell, props}) => <Cell {...cellProps} {...props}>{children}/>, cellProps.children)

For example, the search extension would insert [{Cell: Highlight}] at the beginning of body.views and [{Cell: HeaderSearch, props:{onChange}}] at the beginning of header.views:
const HighLightCell = ({value, search}) => (
    /* series of spans for highlighting generated from value and search */
)
const HeaderSearch = ({search, onChange, children}) => (

    {children}
    <input value={search} onChange={onChange}/>

)

search is passed through propsByCol[relevant id].header.search for each searchable column header, so there needs to be a getPropsByCol() created from the extensions for augmenting the propsByCol before passing it to Table.
Components
<Reactabular.Table [Table='table'] ...restProps/>
Renders the Table element with ...restProps.
 could render a straight div as well, for example.
<Reactabular.Body columns [propsByCol] data [Row='tr'] [props] [Wrap='tbody'] ...restProps/>
results in
<Wrap {...restProps}>

   <Row key={rowData.id} {...props}>

        <CellWrap key={col.id} {...col.body.wrapProps}>
            <Cell colId={col.id} rowData={rowData} value={rowData[col.id]} {...col.body.props} {...propsByCol[col.id].body}>
              {rowData[col.id]}
            </Cell>
        </CellWrap>
   </Row>
</Wrap>

<Reactabular.Header columns [propsByCol] [Row='tr'] [props] [Wrap='thead'] ...restProps/>
results in
<Wrap {...restProps}>
   <Row {...props}>

        <CellWrap key={col.id} {...col.header.wrapProps}>
            <Cell colId={col.id} rowData={rowData} value={rowData[col.id]} {...col.header.props} {...propsByCol[col.id].header}>
              {rowData[col.id]}
            </Cell>
        </CellWrap>
   </Row>
</Wrap>

<Reactabular.Table data columns [propsByCol]/>
Shortcut for the most common case:
<Reactabular.Table>
    <Reactabular.Header columns={columns} propsByCol={propsByCol}/>
    <Reactabular.Body columns={columns} data={data} propsByCol={propsByCol}/>
</Reactabular.Table>

(so do this if data is defined)
Note that thanks to the granular prop passing, only the things that actually need to change will get different props.
Example
const columnDefs = [
    {id: 'birthDate', sortable: true, initialSort: -1, body: {views: [{Cell: DateValue}]}},
    {id: 'name', sortable: true, searchable: true},
]
class BirthdaysTable extends React.Component {
   state = {}
   handleState =
   componentWillMount() {
       // just adlibbing here
       const getState = name => () => this.state[name]
       const onState = name => state => this.setState({[name]: state})
       this.exts = makeExts(
           sortable({getState: getState('sort'), onState: onState('sort')}),
           searchable({getState: getState('search'), onState: onState('search')}),
       )
       this.columns = this.exts.wrap(columnDefs)
       this.rows = wrapForColumns(this.columns, this.props.people
   }
   render() {
     const {rows, columns} = this
     const data = this.exts.getRows(rows)
     const propsByCol = this.exts.getPropsByCol()
     return <Reactabular.Table {...{data, columns, propsByCol}}/>
  }
}

Notes

I waffled between making views an array of Cells that is rendered with each Cell wrapping the previous one and its props, or declaring a single Cell that gets the child Cell and props as props. Both ways allow passing components that don't change; the array approach allows using any regular component, but the nested Cell approach requires that Cells are custom-made, and that
Why not render functions?

Philosophy: React is about nesting components. It is easy to think about components and pass them around, harder to think about render functions.
Debugging: Render functions do not show up in the React tree, harder to debug
Efficiency: By passing components with separate props, shouldComponentUpdate can simply look at all the props without special-casing render functions.

We could also ship a default Cell that looks at column.type and renders appropriately for dates, bools, numbers etc. Same for searching and sorting.

Hi,
That's a solid design. A couple of points:

Column getValue - table-resolver might be able to deal with that, but if it's a common enough needs, maybe it needs to be on the core level (probably better for perf too).
propsByCol -> propsByColumn would read better.
makeExts -> makeExtensions - same here.
wrapForColumns feels weird on a first look.
cellWrap = 'th', wrapProps -> cell: { wrap: 'th', props: {} } would feel better, but it's harder for SCU so maybe the original is justified.

Looking good overall. 👍

I adjusted the text.

getValue seems like a nice API, even for table-resolver. Perhaps there could be a sugar prop .
"attributePath"? In any case, makeResolver can go in table-resolver. It would handle the wrapper class creation for rendering and/or WeakMap for reverse lookup
wrapProps: I'd like to avoid calling any functions per-row for props, since they have opaque data flow. By forcing the use of static props, the dev has to implement in a way most fitting with sCU

I'm a little unsatisfied with the extension state management; it seems a bit clunky now, but it needs to be flexible enough to store and update state anywhere (local, redux, url, server, …). How about expecting an object that has state and setState? Each extension would map to their own key, and it is probably easy to convert to whatever external state management desired.

getValue seems like a nice API, even for table-resolver. Perhaps there could be a sugar prop .
"attributePath"? In any case, makeResolver can go in table-resolver. It would handle the wrapper class creation for rendering and/or WeakMap for reverse lookup

I have a feeling attributePath would be too weak.
If we expose sugar, might as well expose a function interface. I know it comes with some overhead but maybe not too much. I would rather go with getValue. I wonder if it would be possible to merge the concepts of id and getValue as value. id could be overloaded to accept a string and a function. Would that defeat the point of the design?

I'm a little unsatisfied with the extension state management; it seems a bit clunky now, but it needs to be flexible enough to store and update state anywhere (local, redux, url, server, …). How about expecting an object that has state and setState? Each extension would map to their own key, and it is probably easy to convert to whatever external state management desired. In the easy case, you'd then just pass this.

Going through a state and setState pair makes sense to me. I wrote similar APIs for lots of packages that are around reactabular. This gives a good amount of control and allows you to adapt to any system you like as long as you implement the adapter.
I suppose with good design you could share an adapter (redux, whatever) across different adapters (feels like a factory that returns the pair).

So that initialization could instead look like
  componentWillMount() {
    this.extensions = makeExtensions(
      sortable({store: this}),
      searchable({store: this}),
    )
    this.columns = this.extensions.extendColumns(columnDefs)
    this.resolveRows = makeResolver(this.columns)
    this.rows = this.resolveRows(this.props.people)
    // Also would need componentWillReceiveProps to update rows
  }

(update: but see below)
Another thought: We can very easily extend this to also incorporate a footer, which could process the rows to calculate sums etc, just by providing the Footer element and the definitions in the columns. Summary extensions can do their thing when calculating the column props.
...Much thinking ensued. Here's more about how the extensions work:
Thinking about the information flow in a general case. We assume that our table display is a derivation from input data, column definition and extension list + state only. We assume that extensions are called on intermediate data in (reverse) list order for any processing steps.

Configuration step

The full configuration for table rendering is in columns + the list of extensions and their config
columns are defined and then augmented by extensions
can/should be done outside of render()

Prepare step

Raw data has to be resolved for filtering and rendering.

I think a wrapper object a nice way to do this
Alternatively, manually call getValue on every access, which is like virtual wrapping but you can't store a cache on a virtual object. Let's not do this.

After sorting/filtering, it can be useful to map from the transformed data to the original data and index.

This can be done with a WeakMap or by storing the index on a reserved attribute like __index

The actual implementation can be done by an extension
Extensions can add extra data, like metadata for tree views
can/should be done outside of render()

Transform step

We assume every table row maps to only 1 original row. For aggregation, process the data before passing it to the table component.
Extensions sort/filter/aggregate/adjust the resolved data based on their state
Extensions also generate props for the columns
transform({rows, propsByColumn = {}}) => ({rows, propsByColumn})

propsByColumn may be mutated. Maybe we need a helper function.
rows may also be mutated, we'll keep a copy of the prepared rows.
row data may be mutated, but in a way that does not break subsequent transforms

can/should be done outside of render(), whenever state changes

Render step

Filter/order columns if desired
Given the columns, transformed rows, and props, let React do its thing.
Maybe we should rename data to rows in the react components? Then you can do `

I think I have everything, so this points to each extension defining adjustColumns, prepare, transform (any combo), based on given options if it is a factory. An almost always-needed extension would be resolve, not a factory.
To prepare the final table processor, take a list of extensions and compose with composeExtensions(list). You get {adjustColumns, prepare, transform} back.
Maybe  column hide/move should  also fully be an extension. The processor would keep the adjusted columns internally, so then the API would be
const store = this
const extensions = [pager({store}), sorter({store}), filterer({store})]
// calls extension.adjustColumns(columns)
const processor = makeProcessor(extensions, columns)
// calls extension.prepare(rows)
const prepared = processor.prepare(this.props.rows)
// calls extension.transform({rows, propsByColumn})
const {rows: data, columns, propsByColumn} = processor.transform(prepared)
return

This assumes the store already being given to the initialized extensions. Perhaps the store can also be first class, so we get:
const store = this // or tableStoreFromRedux() or whatever
const extensions = [pager({perPage: 10}), sorter, filterer]
// calls extension.adjustColumns({columns, store})
const processor = makeProcessor({extensions, columns, store})
// calls extension.prepare({rows, store})
const prepared = processor.prepare(this.props.rows)
// calls extension.transform({rows, propsByColumn, store})
const {rows: data, columns, propsByColumn} = processor.transform(prepared)
return

Examples:
So suppose you want to show a table with sections by month, each with their own footer. Can this be done using this model? 👉  Yes: You would section the row data to be per month and render a header/body/footer per month using shared columns/extensions/state.
Suppose you want tree data. How do you show? 👉 in the Transform step, hide hidden subtree rows, and in the Configuration step add a leftmost column that shows the position in the tree. To open a tree, store the state in the resolved row. For sorting/filtering, the tree extension has to be split in two, a hiding step before sort+filter and a subtree sort + parent restore afterwards.
...it looks like we can make Reactabular always easy, thanks to extensions…

I think the only question I have at this point is that would it make to push the idea of resolving as an extension?
That would lead to design like this:
componentWillMount() {
  this.extensions = makeExtensions(
    sortable({store: this}),
    searchable({store: this}),
    resolvable(???),
  )
  this.columns = this.extensions.extendColumns(columnDefs)
  this.rows = this.props.people; // resolve later internally?
  // Also would need componentWillReceiveProps to update rows
}

Would this give enough access for a resolve pass, though?

I agree, resolve should be an extension, I forgot to add it to the example
const store = this // or tableStoreFromRedux() or whatever
const extensions = [pager({perPage: 10}), sorter(), filterer(), resolver]
// calls extension.adjustColumns({columns, store}) (e.g. resolver creates wrapper class)
const processor = makeProcessor({extensions, columns, store})
// calls extension.prepare({rows, store}) (e.g. resolver wraps in wrapper)
const prepared = processor.prepare(this.props.rows)
// calls extension.transform({rows, propsByColumn, store})
const {rows: data, columns, propsByColumn} = processor.transform(prepared)
return

Ok. How do you want to proceed with this? Can you start a PR? I don't mind reviewing and giving feedback but apart from that I'm a bit tight on time till I get the book out.

I'll adjust the notes above and give it some more time to think about and then start a PR yes. Don't have much time either but I think it won't actually be that much work, mostly copying things around.

Ok, cool. I have a feeling you did most of the hard work already. 👍


try RCTs and custom WP also for single-group images

In the case that the whole image fits in the GlobalModular section, the encoder wasn't trying different RCTs and different WP params, since that code was only being run for the ModularDC and ModularAC sections. This fixes that, which should lead to slightly denser lossless compression of images smaller than 256x256.
A side effect of this change seems to be that a test related to partial codestream boxes (jxlp) is now failing — likely that is unrelated to this change, so for now I have manually disabled those tests.
@lvandeve PTAL at the failing test (see the change in decode_test.cc in this PR). I tried finding the problem but I'm not familiar with the relevant code.

@jonsneyers thanks for finding this bug, it's indeed a bug and should be fixed with https://github.com/libjxl/libjxl/pull/664
I'm also working on further simplifying the box handling for future PRs

Rebased and re-enabled the test that was failing.

This is great news :) Here's the old/new sizes for a 13000x12000 tiff container using 256x256 jxl tiles, using different speed tiers:
444028210 jxl-3-new.tif
444028210 jxl-3.tif

427696856 jxl-5-new.tif
522358734 jxl-5.tif

427629507 jxl-7-new.tif
522965125 jxl-7.tif

425612715 jxl-9-new.tif
522582647 jxl-9.tif


[Joy] Add Chip component

[x] I have followed (at least) the PR section of the contributing guide.

This PR includes:

correcting typos in Joy SvgIcon demo / Joy Avatar demo / Joy Avatar API code
addition of Joy Chip component
tests for Joy Chip component

Props: startDecorator, endDecorator, color, size, variant, disabled
Default values:

color: primary
size: md
variant: contained
disabled: false

I removed onDelete, icon, avatar, label, clickable and deleteIcon props and added startDecorator / endDecorator following up with this discussion
Preview: https://deploy-preview-31983--material-ui.netlify.app/experiments/joy/chip/
Lines of code comparison

Material
Joy
% change

Chip
560
350
-37.50

ChipDelete

148

total
560
498
-11.07

From the issues that I can find:

https://github.com/mui/material-ui/issues/20470
https://github.com/mui/material-ui/issues/16097
https://github.com/mui/material-ui/issues/19468

I am thinking about these changes

Can we get rid of the label prop and use the same old children prop? This will give the same experience across other components. However, the slot label is needed to create text-overflow ellipsis.

// implementation
<ChipRoot>
 ...startDecorator
  <ChipLabel>{children}</ChipLabel>
 ...endDecorator
</ChipRoot>

// usage
<Chip>text</Chip>

introduce ChipButton, and ChipDelete component instead of using clickable, onDelete and deleteIcon prop. This would make the Chip API cleaner since it already exposes start/endDecorator. Here is what the usage looks like in https://github.com/mui/material-ui/issues/20470#issuecomment-1078932178

@hbjORbj Could you replicate some of these design inspirations in the /experiments/joy/chip/ page to verify the flexibility of the new Chip component?

https://dribbble.com/shots/13386064-React-design-system-UI-kit-Chips-Select-Filters-for-Figma
https://www.figma.com/file/cEWBQUmVbQpXP25YvZNSCo/Material-Desktop-System-Demo?node-id=0%3A149
https://blog.prototypr.io/react-material-ui-templates-chips-components-e73d664da85f

@siriwatknp

Can we get rid of the label prop and use the same old children prop? This will give the same experience across other components. However, the slot label is needed to create text-overflow ellipsis.

Yes, I can do that.

introduce ChipButton, and ChipDelete component instead of using clickable, onDelete and deleteIcon prop. This would make the Chip API cleaner since it already exposes start/endDecorator. Here is what the usage looks like in https://github.com/mui/material-ui/issues/20470#issuecomment-1078932178

Yes, I agree it looks better. I will work  on it.

Could you replicate some of these design inspirations in the /experiments/joy/chip/ page to verify the flexibility of the new Chip component?

Sure, no problem.

@siriwatknp

I changed default value for variant and color to contained and primary, respectively
Created a ChipDelete component
Replaced ButtonBase with a HTML button when clickable is true
Made the style more solid

Summary of my changes

Component variables:

remove some variables that are not necessary, eg --Chip-color, --Chip-fontSize
add --Chip-delete-size, --Chip-radius to make customization easier

Markup:

add action slot for creating clickable chip
custom chip delete icon by providing children

Integration:

allow chip to automatically adjust avatar's radius
chip delete's radius also adjust to the chip's radius
the chip control the icon's font-size based on its size
chip delete's variant, color adapt to the root chip

Accesibility: follow https://github.com/mui/material-ui/issues/20470


Limit Note Text Length to Three Lines with Expand Button

Description
Implement a restriction on the length of text in the Note component so that it does not exceed three lines. If the text exceeds this limit, the Expand button should appear at the end of the third line.

CAn I contribute to this

CAn I contribute to this

Yes, you can try to resolve this. Create a separate branch for it and include the issue number in your commit message. Thanks!
@divitttt

The text occupies exactly three lines at most, and the "Expand" button is positioned next to other buttons.


Opening a router link to a modal overrides the router's children

I am using semantic-ui-react with react-router. I created a route to display a modal, the modal trigger is just a router link. when I open the link, the modal is well displayed, but the router children is replaced by a new link.
Is it possible to just show the modal and leave the router children as it is,  whatever it is ?
Thanks in advance.

Use SO for usage question, if you think that there is real issue, please fill issue template and make a repro on codesandbox.

Ok, https://stackoverflow.com/questions/47799507/opening-a-router-link-to-a-modal-overrides-the-routers-children


Remove logic that may not be useful

It seems that this judgment will always be followed by the result

That code is to check if the normal-mode delimiters are already in cache, and only fetch them if they are not in cache.

That code is to check if the normal-mode delimiters are already in cache, and only fetch them if they are not in cache.

But here's a judgment, if it is executed, it must be worthless?
https://github.com/kylechui/nvim-surround/blob/0c02c52182a9c2a7fa7e122b4037f6408e98434a/lua/nvim-surround/init.lua#L283

Woops, completely missed those. Thanks for the catch!


[Bug] Clearing a DatePickerField doesn't allow you to pick the same date without changing it first

Using the following steps, you will see that the DatePickerField will not allow you to reselect the same date after clearing it:

In a DatePickerField, select some date
Clear the date via the clear 'X' button
Reselect the same date
Notice that the new date is not in the DatePickerField

Edit --
This is also true when nothing is selected and you attempt to select today's date.

This is strange behavior. I found the reason but hadn't seen any solution yet.

I found the reason but hadn't seen any solution yet.

Can you shed some light as to what you found the reason to be, and what the problem is (i.e., why is it stuck?). This is still affecting us...
Alternatively, any workarounds?
Thanks.

Since it uses default MAUI datepicker, clearing works only on the UI side. The original datepicker still keeps the date because it doesn't support null values. I'll try add some native code with Custom Handlers to overcome this issue

I just wanted to give this issue a gentle bump. ;)
This is still the case and observable in the demo DatePickerFieldPage, where Date is initially null, and cannot even be set to the current date by invoking the picker and clicking ok.

I have an issue where the initial value is displayed, with a low opacity, behind the title until a new value is selected. XAML code is as follows:
                    <material:DatePickerField
                        Date="{Binding OpeningBalance.Date, Mode=TwoWay}"
                        Format="dd-MMM-yy"
                        Title="Date"
                        WidthRequest="150" >
                        <validation:RequiredValidation />
                    </material:DatePickerField>

Is this related to this issue or something different?

Regarding the original bug, it is the Maui DatePicker that is the issue. This issue has been open for over a year without resolution - [(https://github.com/dotnet/maui/issues/13156)].
There is a work around mentioned in the issue that could be implemented here.
 public class FormDatePicker : Microsoft.Maui.Controls.DatePicker, IDatePicker
 {
     DateTime IDatePicker.Date
     {
         get => Date;
         set
         {
             if (value.Equals(DateTime.Today.Date))
                 Date = value.AddDays(-1);
             Date = value;
             OnPropertyChanged(nameof(Date));
         }
     }
 }

@enisn I created a pull request, please take a look. Tested successfully in UraniumApp.

Thanks for your contribution, I'll check as soon as possible and try to release it quickly after merged

@enisn Petition to reopen this since #835 invalidated the fix from #804


Incorrect variable in test output

Looks like a copy-paste bug from the same test for the image manifest.
Signed-off-by: James Hewitt<EMAIL_ADDRESS>

Codecov Report

Merging #3613 (25bd1f7) into main (a6047a8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #3613   +/-   ##
=======================================
  Coverage   56.33%   56.33%
=======================================
  Files         101      101
  Lines        7313     7313
=======================================
  Hits         4120     4120
  Misses       2536     2536
  Partials      657      657

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a6047a8...25bd1f7. Read the comment docs.


WIP: switch compute ctl to background process

Problem
Summary of changes
Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.
[ ] Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
[ ] If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

[ ] Do not forget to reformat commit message to not include the above checklist

Abandoning this PR, as I don't work on compute_ctl and it got too stale.


Unable to load FFProbe and Executable not found, proposed : avprobe, ffprobe

Hi there,
I'm trying to run PHP-FFMpeg on a server and I get the following error:
2/2
ExecutableNotFoundException in FFProbeDriver.php line 50:
Unable to load FFProbe
1/2
ExecutableNotFoundException in AbstractBinary.php line 160:
Executable not found, proposed : avprobe, ffprobe
The result of these:
var_dump(getenv('PATH'));
var_dump(exec('which ffmpeg'));
var_dump(ini_get('open_basedir'));
var_dump(is_file(exec('which ffmpeg')));
var_dump(is_executable(exec('which ffmpeg')));
is here:
string(29) "/sbin:/usr/sbin:/bin:/usr/bin"
string(15) "/usr/bin/ffmpeg"
string(74) "/home/video/:/tmp:/var/tmp:/usr/local/lib/php/:/usr/local/php56/lib/php/"
bool(false)
bool(false)
So I don't have any idea why is not working?
any suggestions?

Duplicate of https://github.com/PHP-FFMpeg/PHP-FFMpeg/issues/172
So far I didn't found an solution. 😭


Add support for Canvas placement data

Canvas appears to send the placement from which a tool was launched in the https://www.instructure.com/placement claim.

Not sure where all of the possible values are documented.


Multiplayer Home Page

Need to design and implement a page where players can decide to Join or Host a game. This page should probably also prompt for sign-in.

@eanders-ms addressed this with https://github.com/microsoft/pxt/pull/9154.


Scheduled Task Creation failed

Describe the bug
When creating a Windows Scheduled Task, we received an error: " The current version of the native library (1.6) does not support the version of the "[Task Name]" task (0.0)"
To Reproduce
Steps to reproduce the behavior:
In the particular piece of code we are working with, there are two types of actions performed:

TaskService.Instance.AllTasks in which it updates a scheduled task's Definition.Settings.ExecutionTimeLimit and Definition.Settings.StartWhenAvailable and then calls RegisterChanges()
TaskService.Instance.AddTask in which it creates a new task with additional settings of the Definition.Principal.UserId, Definition.Settings.ExecutionTimeLimit, Definition.Settings.Enabled, and Definition.Settings.StartWhenAvailable and then calls Definition.Triggers.Clear() and RegisterChanges()

Environment (please complete the following information):

Windows Version: Windows 21H1 19043.1083
Library Version: 2.8.4

This is curious. I can only guess that there is a task on the machine that, when its XML is requested, returns one without a version tag. The code can be found here.
It could be the order or way that you're calling the methods on the retrieved tasks. Do you mind sending your code for the two examples above?

Sure here is the code from the examples above.
TaskScheduler Examples.txt

I've run the following code without errors on my Windows 10 21H1 19043.1110 system with lib version 2.9.2.
foreach (Task t in TaskService.Instance.AllTasks)
{
   foreach (ExecAction action in t.Definition.Actions.OfType<ExecAction>().
      Where(a => string.Equals(a.Path, cmdPath, StringComparison.InvariantCultureIgnoreCase) &&
         string.Equals(a.Arguments, args, StringComparison.InvariantCultureIgnoreCase)))
   {
      t.Definition.Settings.ExecutionTimeLimit = TimeSpan.FromDays(1);
      t.Definition.Settings.StartWhenAvailable = true;
      t.RegisterChanges();
   }
}
var task = TaskService.Instance.AddTask("Temp", new DailyTrigger(1) { StartBoundary = DateTime.Now },
   new ExecAction(commandProgramPath, args), "SYSTEM", null, TaskLogonType.ServiceAccount);
task.Definition.Settings.ExecutionTimeLimit = TimeSpan.FromDays(1);
task.Definition.Settings.StartWhenAvailable = true;
task.Definition.Triggers.Clear();
task.Definition.Settings.Enabled = false;
task.RegisterChanges();

@puzzled-paradox  Did the sample code above solve your issue?

Yes, thank you very much


MM-15943 remove divider above plugin menu items

Summary
Remove divider between normal menu items and plugin menu items on dot menu. Is now rendered in the main web app.
Ticket Link
https://github.com/mattermost/mattermost-server/issues/11054
https://mattermost.atlassian.net/browse/MM-15943
Related Pull Requests
https://github.com/mattermost/mattermost-webapp/pull/3264

Thanks @janvt for the PR!
Integrations team: noting that support for this is dependant on https://github.com/mattermost/mattermost-webapp/pull/3264, which will be scheduled for 5.16 earliest. So we may need to bump up the minimum server requirement after this PR is merged, or as part of it.

It's worth noting that installing this on versions prior to Mattermost 5.16 will "break" the existing divider. Should we add a hard dependency in the plugin.json, or just accept that as a transient issue and move on?

It's worth noting that installing this on versions prior to Mattermost 5.16 will "break" the existing divider. Should we add a hard dependency in the plugin.json, or just accept that as a transient issue and move on?

Break how?  Is there a screenshot?

@aaronrothschild, since the JIRA plugin will now rely on the server to manage the divider, this will likely result in the following (faked) interface:

Just want to make sure we're on the same page. I don't think it's a major issue, but if we wanted to expend the extra effort, we might be able to conditionally add the divider from the JIRA plugin based on the server version.

Thanks for the headsup, not a major issue and not worth the effort IMO.


Registry tries creating already existing bucket v.12.1

Just upgraded to v.12.1 and the registry throws S3 errors. Previous similar errors in v.11 have been resolved with the fix mentioned in #4710.
We are using a cephless cluster on AWS.
Deis tries to create bucket even if it already owns it.
Nov 05 08:17:32 ip-10-21-2-170.eu-west-1.compute.internal sh[30590]: registry: creating bucket
Nov 05 08:17:32 ip-10-21-2-170.eu-west-1.compute.internal sh[30590]: Traceback (most recent call last):
Nov 05 08:17:32 ip-10-21-2-170.eu-west-1.compute.internal sh[30590]: File "/app/bin/create_bucket", line 21, in <module>
Nov 05 08:17:32 ip-10-21-2-170.eu-west-1.compute.internal sh[30590]: conn.create_bucket(name)
Nov 05 08:17:32 ip-10-21-2-170.eu-west-1.compute.internal sh[30590]: File "/usr/lib/python2.7/site-packages/boto/s3/connection.py", line 616, in create_bucket
Nov 05 08:17:32 ip-10-21-2-170.eu-west-1.compute.internal sh[30590]: response.status, response.reason, body)
Nov 05 08:17:32 ip-10-21-2-170.eu-west-1.compute.internal sh[30590]: boto.exception.S3CreateError: S3CreateError: 409 Conflict
Nov 05 08:17:32 ip-10-21-2-170.eu-west-1.compute.internal sh[30590]: <?xml version="1.0" encoding="UTF-8"?>
Nov 05 08:17:32 ip-10-21-2-170.eu-west-1.compute.internal sh[30590]: <Error>BucketAlreadyOwnedByYou<Message>Your previous request to create the named bucket succeeded and you already own it.</Message><BucketName>dreicloud-deis-khan</BucketName><RequestId>381338F14C6E9FB1</RequestId><HostId>RyvNTqiBMN7KDhjOQcp7u8WaCBwEG3AlyZ80yx6EUECb54ICRIu+d7wLjDIx6MUKQFLkb53M83Y=</HostId></Error>

+1 I hit this same issue. It was worse when using the policy defined in the docs. I got a 403 error with that. I broadened my permissions and got further and now get this error. I haven't figured out a workaround yet. I don't know python, but i was looking at the Boto docs and I read that the lookup function returns "none" if the bucket isn't found. Is the conditional working correctly? I would assume so, this change has been in for several weeks, but I thought I'd mention that.

It's possible that the change introduced in https://github.com/deis/deis/pull/4566 caused this regression. Given the following expression:
if not conn.lookup(name):

My guess is that the correct lookup should be
if conn.lookup(name) is not None:

I'll hack up a patch and let you guys try it out.

awesome!

@bacongobbler Thanks for this. I just tested this and it doesn't seem to work for me (deisctl config registry set image=cyberphysical/registry:git-cf12b88). I still get the same 409 error.
Nov 06 03:15:35 ip-10-21-1-4.eu-central-1.compute.internal sh[32243]: registry: creating bucket
Nov 06 03:15:36 ip-10-21-1-4.eu-central-1.compute.internal sh[32243]: Traceback (most recent call last):
Nov 06 03:15:36 ip-10-21-1-4.eu-central-1.compute.internal sh[32243]: File "/app/bin/create_bucket", line 18, in <module>
Nov 06 03:15:36 ip-10-21-1-4.eu-central-1.compute.internal sh[32243]: conn.create_bucket(name)
Nov 06 03:15:36 ip-10-21-1-4.eu-central-1.compute.internal sh[32243]: File "/usr/lib/python2.7/site-packages/boto/s3/connection.py", line 616, in create_bucket
Nov 06 03:15:36 ip-10-21-1-4.eu-central-1.compute.internal sh[32243]: response.status, response.reason, body)
Nov 06 03:15:36 ip-10-21-1-4.eu-central-1.compute.internal sh[32243]: boto.exception.S3CreateError: S3CreateError: 409 Conflict
Nov 06 03:15:36 ip-10-21-1-4.eu-central-1.compute.internal sh[32243]: <?xml version="1.0" encoding="UTF-8"?>
Nov 06 03:15:36 ip-10-21-1-4.eu-central-1.compute.internal sh[32243]: <Error>BucketAlreadyOwnedByYou<Message>Your previous request to create the named bucket succeeded and you already own it.</Message><BucketName>eu.cdp.deis</BucketName><RequestId>D7825D290AB3B5B2</RequestId><HostId>+Vm4bqAHwziU7nYGFvgnjTtNugjhAb1xSwVECFYEC1d99n1XjepnIwuAJloOVtos</HostId></Error>

Ok! I have something to report. My bucket was in Frankfurt, eu-central-1. There's a known boto issue with this region and S3. I was able to work around this by setting host/port.
deisctl config store/gateway set host=s3.eu-central-1.amazonaws.com
deisctl config store/gateway set port=80

I was able to work around this by setting host/port.

You got it to work after that?
I did the same with Ireland now.
deisctl config store/gateway set host=s3.eu-west-1.amazonaws.com
deisctl config store/gateway set port=80

Now I get signature errors (at least a step further).  I am quite sure it is not the access key because I did not modify anything there and in the v1.11 version it worked with those keys.
ov 06 07:50:02 ip-10-21-2-170.eu-west-1.compute.internal sh[10045]: registry: creating bucket
Nov 06 07:50:03 ip-10-21-2-170.eu-west-1.compute.internal sh[10045]: Traceback (most recent call last):
Nov 06 07:50:03 ip-10-21-2-170.eu-west-1.compute.internal sh[10045]: File "/app/bin/create_bucket", line 24, in <module>
Nov 06 07:50:03 ip-10-21-2-170.eu-west-1.compute.internal sh[10045]: conn.create_bucket(name)
Nov 06 07:50:03 ip-10-21-2-170.eu-west-1.compute.internal sh[10045]: File "/usr/lib/python2.7/site-packages/boto/s3/connection.py", line 621, in create_bucket
Nov 06 07:50:03 ip-10-21-2-170.eu-west-1.compute.internal sh[10045]: response.status, response.reason, body)
Nov 06 07:50:03 ip-10-21-2-170.eu-west-1.compute.internal sh[10045]: boto.exception.S3ResponseError: S3ResponseError: 403 Forbidden
Nov 06 07:50:03 ip-10-21-2-170.eu-west-1.compute.internal sh[10045]: <?xml version="1.0" encoding="UTF-8"?>
Nov 06 07:50:03 ip-10-21-2-170.eu-west-1.compute.internal sh[10045]: <Error>SignatureDoesNotMatch<Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><AWSAccessKeyId>AKIAJTGY74B5G46O6ZDQ</AWSAccessKeyId><StringToSign>PUT
Nov 06 07:50:03 ip-10-21-2-170.eu-west-1.compute.internal sh[10045]: Fri, 06 Nov 2015 07:50:03 GMT
Nov 06 07:50:03 ip-10-21-2-170.eu-west-1.compute.internal sh[10045]: /s3.eu-west-1.amazonaws.com/dreicloud-deis-khan/</StringToSign><SignatureProvided>YisQa8xfnNv3/6Gi0j3XDn1QExE=</SignatureProvided><StringToSignBytes>50 55 54 0a 0a 0a 46 72 69 2c 20 30 36 20 4e 6f 76 20 32 30 31 35 20 30 37 3a 35 30 3a 30 33 20 47 4d 54 0a 2f 73 33 2e 65 75 2d 77 65 73 74 2d 31 2e 61 6d 61 7a 6f 6e 61 77 73 2e 63 6f 6d 2f 64 72 65 69 63 6c 6f 75 64 2d 64 65 69 73 2d 6b 68 61 6e 2f</StringToSignBytes><RequestId>20455044797F4573</RequestId><HostId>ICvJpaRJalYvQBR8hDP1Q/6w2H0Kl//eFa13MR++LwMzMgk/DSjFqXUmDhb+BUa0qfMpriDmKwI=</HostId></Error>

With the fix provided deisctl config registry set image=cyberphysical/registry:git-cf12b88
and host and port settings removed I get the same old error.
Error>BucketAlreadyOwnedByYou<Message>Your previous request to create the named bucket succeeded and you already own it.</Message><BucketName>dreicloud-deis-khan</BucketName><RequestId>4AC30E3D648FC3EC</RequestId><HostId>xBXU3tP3+ykTbXapvTwIkL8M1EG4yGEeGSlYO+vOsHHbj8bx4R+F6vNANYdy1Z8p</HostId></Error>

@lukasmartinelli What I did to debug was to run the registry container adhoc using "bash" as the command to override the "boot" command. I then ran the boot script (which failed, but triggered confd to populate the files). Then I edited the create_bucket script by adding a print conn.get_bucket(name) line which allowed the real/hidden error to surface. I could then run "create_bucket" manually to find my error.

@afterthought @lukasmartinelli if you guys can supply a doc which explains how you set up your ceph-less clusters, I'd be happy to reproduce and see what's going on.

@bacongobbler I'm all set right now. I will post a gist though of my setup script.

@lukasmartinelli that SignatureDoesNotMatch error typically means that your S3 access key and secret key are incorrect. Are you sure that deisctl config registry get s3accessKey and deisctl config registry get s3secretKey are correct?

I haven't tested the ssl settings yet which are in this script. What's running now has port set to 80, not 443.
https://gist.github.com/afterthought/bb4f430906c5bc1f6379

I've been playing about with boto in ipython, and this appears to be down to conn.lookup() not working with OrdinaryCallingFormat:
In [20]: conn = boto.connect_s3(aws_access_key_id='', aws_secret_access_key='', is_secure=False)

In [21]: conn.lookup('rp-deis')
Out[21]: <Bucket: rp-deis>

In [22]: from boto.s3.connection import OrdinaryCallingFormat

In [23]: conn = boto.connect_s3(aws_access_key_id='', aws_secret_access_key='', is_secure=False, calling_format=OrdinaryCallingFormat())

In [24]: conn.lookup('rp-deis')

Prior to #4566 conn.get_all_buckets() was used instead, which does seem to work with OrdinaryCallingFormat https://github.com/rvaralda/deis/blob/2333ccdc19969a6affa1b8b2225b88d186a2af33/registry/templates/create_bucket#L25

Great sleuthing, @obmarg! It looks like the short-term solution is probably to revert #4566, right?

Seems like the least risky proposition - I'm assuming the script uses OrdinaryCallingFormat for a reason.

I'm assuming the script uses OrdinaryCallingFormat for a reason

It's required to talk to to the Ceph storage gateway - by default, it will assume that we're accessing bucket.<endpoint>. By using OrdinaryCallingFormat, boto composes the host as <endpoint>/bucket, which is how the Ceph gateway is accessed.

I read in the boto issues that OrdinaryCallingFormat was needed for bucket names with "." in them. You might be introducing a new class of bugs if you move away from it. My bucket name has "." in it right now. I can change that though of course.

You might be introducing a new class of bugs if you move away from it.

Yeah, I don't think we can move away from it. But #4566 replaced the get_all_buckets call to reduce the permissions an IAM user needed - this change in lookup method seems to be the issue.

None of the various potential solutions matter until we understand each root issue. My root issue was that for the eu-central-1 region I needed to force the hostname used. @lukasmartinelli above mentioned that when he removed the host/port....

With the fix provided deisctl config registry set image=cyberphysical/registry:git-cf12b88
and host and port settings removed I get the same old error.

BucketAlreadyOwnedByYouYour previous request to create the named bucket succeeded and you already own it.dreicloud-deis-khan4AC30E3D648FC3ECxBXU3tP3+ykTbXapvTwIkL8M1EG4yGEeGSlYO+vOsHHbj8bx4R+F6vNANYdy1Z8p

That he reverted to this error. But we still don't know what @lukasmartinelli root issue really is. I mentioned above the steps I used to find it.

What I did to debug was to run the registry container adhoc using "bash" as the command to override the "boot" command. I then ran the boot script (which failed, but triggered confd to populate the files). Then I edited the create_bucket script by adding a print conn.get_bucket(name) line which allowed the real/hidden error to surface. I could then run "create_bucket" manually to find my error.

A systematic fix would be to call get_bucket(name) instead of lookup and handle the exception. If it's truly a 404 (or whatever S3 returns for bucket not found) then create the bucket, otherwise, we want to expose the real error returned so that "us users" can diagnose and fix our permission/config issue without creating deis bugs (if it's not a deis bug).

When I call get_bucket with OrdinaryCallingFormat I get a 302:
In [42]: conn.get_bucket('rp-deis')
S3ResponseError: S3ResponseError: 301 Moved Permanently

Which is presumably why lookup is returning None.

I got 301 too. Hmm. That's what lead me to find the specific workaround for eu-central-1.

Ahh... I bet the issue is that we have to conditionally use OrdinaryCallingFormat only when we're using Ceph. If using an external store (like S3), we shouldn't have to specify the calling format.
So, we can either make callingFormat an etcd key that can be configured, or create a new key that toggles whether or not we're using an external backing store. Right now we infer based on certain keys being set, but this is already confusing - see #4668.
Could you guys try a version of this file without specifying the calling format and see if that works?

I've deployed a cluster using my fork here: https://github.com/obmarg/deis/commit/5d949ef6d6a78c2d7208cb8c8e418169a3d623b5 and it works fine.
deisctl --tunnel=$NEW config registry set image=obmarg/deis-registry if anyone else wants to try.

A key that configures callingFormat sounds like a good idea to me.  Might be good to be able to configure  is_secure too - don't know about anyone else, but I don't like the idea of not using SSL for S3 (even if I am on amazons network)

:+1: @obmarg if you want to PR that, I think configuring the options in that file is a good approach.

Yeah I'll try and tidy it up and make a pr soon.

I've deployed a cluster using my fork here: obmarg@5d949ef and it works fine.

Yeah! Works for me. Thanks for the fast response.

Thanks for your help in debugging this, everyone! @obmarg's changes have gone into Deis v1.12.1, which was released today. Upgrade and this should be fixed. :+1:


fix(nuxt): plugin injection on latest Nuxt 3 context

As Nuxt 3 removed the legacy context (https://github.com/nuxt/framework/pull/5630), the inject argument and nuxtState option is not available anymore.
Fixes #1428
fix #1432

Thanks, I will take a look. I think we will also need to migrate to nuxt/kit. It was removed in the past due to some missing features but it should be ready now

Nuxt kit is now stable to migrate to but buntime part (of plugins) can be upgraded to bridge. Kit utils are only for module/build level not runtime.

@posva  will you tag new version?

I can get to $auth by way of useNuxtApp() in components and composables, but how would you access it in a Pinia store?
In components, I usually just do:
const nuxtApp = useNuxtApp();
const authUser = nuxtApp.$auth.user;

but in a stores/store.ts, useNuxtApp is not available, so I'm not quite sure how to get to the context?
Is this issue the reason - change in context access?


Improve error returns from broker

#2262, @int19h  ```
We do, however, need to improve reporting from the broker for when a session is requested with non-existing interpreter ID (including blank ID when no interpreters are available). Right now we just throw, which gets reported to the client as HTTP 500 error with no body, so it's not possible to distinguish this particular error from any other failure on the broker side.
Probably the easiest way to do this is to add an extra HTTP X-header to the response, that would contain our own error code, if it's an anticipated error (and not a general failure). The client can then check that header if it receives an error response, and display the appropriate error messages.
Also, in many cases, we can just use more specific HTTP status codes instead of 500 (when an exception is unhandled, it's always reported as HTTP 500). This catalog will be helpful:
http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
For the situation when an entity (e.g. an interpreter in this case) is requested, but is not found, it seems that HTTP 422 might be the appropriate status code.

Or we could use something from unassigned ranges like 512-599.
428 Precondition Required or 417 Expectation Failed sound reasonable.

https://github.com/Microsoft/RTVS/commit/03a29d0008f298846bfd06091e155f0dd2967367


Trackstatus is not available for \Inspirum\Balikobot\Definitions\API::V2V2

\Inspirum\Balikobot\Services\Client::trackPackagesLastStatus call trackstatus with version V2V2, but in documentation it's not available - it's same as V2
see https://balikobot.docs.apiary.io/#reference/tracking/trackstatus-v2
I wrote with balikobot and they wrote:

Thank you for reporting this issue.
It have been solved in v7.4.0 by commit 2032939.

I have updated branches 5.x and 6.x to fix this bug. It have been solved in v5.7.1 and v6.2.1.


feat: Add local restore variable

also marks the oidc_secret variable as sensitive.

This PR is included in version 1.4.0 :tada:


Feature request: Add support for passing in a mysql pool to the MySQLHandler

Hello, I would like to request the following feature for the @graphql-mesh/mysql handler. I would like to be able to pass in an existing mysql pool to the constructor object instead of config, when I am using the graphql mesh and its handlers in a programmatic way. In other words, I would like to invert the control of the pool and leave it to the users of the API. So the API should either work with a config or a pool.
Benefits:

Reusing an existing pool.
Adding further functionality, event listeners, etc. around that pool

Potential problem:

This might only be applicable to the programmatic usage of the MySQLHandler, as it would not make sense to pass a pool when using the YAML Config.

I am currently creating a PR for this feature request if you are willing to accept it.
fyi @Kiesen

I created a PR for this feature;
https://github.com/Urigo/graphql-mesh/pull/1158
pool accepts modulePath#exportName or Pool instance directly in programmatic configuration. If you want to stick with .meshrc.yml, you can use findAndParseConfig and getMesh in your application so Pool will be shared.

Ah no. I just created a PR for this, as well. Tried doing my first open-source contribution. Looks like you have done it already 😢 . But anyway, thank you very much

I am sorry :(
Available in the latest versions.

@ardatan , found a minor bug inside the existing implementation for this feature. I have opened a corresponding PR fix.


[Release] v1.0.0

Refactor codesnap.nvim use lower graphic API instead, better perform and take snapshot without running any server in background

[x] Generate snapshot use lower graphic API
[ ] Preset code font & watermark font
[ ] Custom theme
[ ] Update README

build dev


Add FB post publish time to offer groups

@madislehtmets, please style.

@deiwin if the travis stuff is ignorable, then merge?


removed addinfo folder since we are not using the code

deleted addinfo folder since we are not using the code

good


virtcontainers: Fix structured logging in cgroups package

Call the pkg/cgroups package SetLogger() function to ensure all its log
records contain all required structured logging fields.
Fixes: #2782
Signed-off-by: Julio Montes<EMAIL_ADDRESS>

/test-ubuntu

lgtm

@devimc, is this material for stable-1.11?

@fidencio  yes, https://github.com/kata-containers/runtime/pull/2784


Can't see header, progress always 0.003333

I have a UIViewController with a UITableView subview filling the container.
I'm adding an imageView to be the header (I've tried this a few ways, including following the sample project) and can't get the library working.
        let imageView = UIImageView()
        imageView.image = UIImage(named: "placeholder_lg")

        // Parallax Header
        tableView.parallaxHeader.view = imageView
        tableView.parallaxHeader.height = 300
        tableView.parallaxHeader.mode = .fill
        tableView.parallaxHeader.minimumHeight = 20

On view load, the scrollViewDidScroll function is called 4 times and the progresses are:
2016-10-26 11:09:49.388412 fm[1614:1068827] progress 0.000000
2016-10-26 11:09:49.389333 fm[1614:1068827] progress 0.000000
2016-10-26 11:09:49.390372 fm[1614:1068827] progress 0.066667
2016-10-26 11:09:49.390943 fm[1614:1068827] progress 0.066667

After loading, the progress is always 0.003333 on scroll. At no point is the image (or any other view I try to put in the parallaxHeader) visible. Am I missing something obvious here?
Same result on iOS 9 and 10

Nevermind. A subclass was explicitly setting tableViewHeader to nil


Redirect requests to leader

Hi.
The agent vault.url should point to the current leader. It's inconvenient if a vault cluster doesn't have a URL that always points to the leader. The second option - agent should to be installed on all vault hosts.
I guess it will be more convenient to redirect all requests to the vault leader automatically.
Or add new configuration vault.urls: [] which is list of all vault nodes.

Hi @vterdunov,
sorry for the late reply, i somehow missed the notification for this issue :-(
I think, we'd have to do both as in your scenario we cannot know for sure wheter the configured single vault.url is the the leader when the agent starts (or accessible at all) and we have to switch to the leader's address when it changes from one node to an other - and simply trying all nodes  until we find the leader does not seem right (or elegant9 either.
I'll look into it. Is this issue a pressing requirement for you to be able to use the agent in your setup or more nice to have?

Hi @vterdunov,
i've just released v0.10.18 which adds automatic leader-detection to the agent. Please check it out. I'd appreciate your feedback!
Kind regards


Incorrect project path after migration from 7.9 to 7.13

Summary
The path for projects in CI may be malformed if they used SSH instead of HTTPS.
Steps to reproduce
In a gitlab-ci instance at 7.9, edit the project settings to set the GitLab url to project setting to a value other than the HTTPS default. In our case, this was a change to use git@domain.com:group/project since our runners did not trust the internal, self-signed certificate for HTTPS. Once updated, upgrade the instance to 7.13 which will run the migrations.
Now either run a CI job, or click the View on GitLab button when viewing a project. This will result in a URL like:
https://domain.com/git@domain.com:group/project

Expected behavior
The contents of the path to be group/project rather than git@domain.com:group/project.
Observed behavior
The content of path is git@domain.com:group/project.
Relevant logs and/or screenshots
I unfortunately did not save the output from the upgrade, however everything passed and the healthcheck reported clean.
Possible fixes
If I am not mistaken, this problem may be related to migration [20150504010150_migrate_url_to_path.rb] (https://github.com/gitlabhq/gitlab-ci/blob/2e2f8f61549faebdde2021b2c82c2f3d623fc513/db/migrate/20150504010150_migrate_url_to_path.rb) which used a regex to translate the gitlab_url to path. This issue may be a nofix, since it has already happened, but I wanted to be sure I was not missing something obvious.
The option to configure the gitlab url was removed from the settings page, so does that mean the correct recourse is to modify the database by hand to translate them into paths? Also, are we required to use HTTPS instead of SSH as the transport for CI now?

As an update, I corrected the paths in the database by hand and everything seems to be working well - including the use of HTTPS instead of SSH. To detail the workaround...
Find the socket
netstat -nlp | grep 5432

Charade as the owner
ls -lhat <socket>  # to get the owner
su - <owner>

Connect to the db
psql -h <socket_dir> gitlab_ci_production

Show info
\dt  # show tables
\d+ tablename # describe table

Collect and correct projects with malformed paths
select id, path from projects where path like 'git@%';

Took the output of that query, threw it in my favorite editor, used vertical edits to generate oneliner commands for each project which look like:
update projects set path='group/project' where id=#;

Could have done that with a subquery, but this was much easier/faster for a one-off. With this workaround I think I should be good, and anyone else in this situation can recover as well, but I'll wait for a confirmation here before closing.


fix(addon-mobile): Card fix paddings on mobile devices

Close #8939
The mobile paddings now look good in the demo. Not sure if they are applied correctly IRL on mobile device.

Thank you for not just reporting, but finding time to actually fix the issues 🤝


i can't launch a custom ver

https://youtu.be/6Y3X005QZKA

can you show me what the launcher log says?

it should be fixed now


Rework PGDS surface

@alastai Ready for another round of review.

@alastai We merged the PR for now to avoid conflicts with other PRs. Please add comments if this requires additional changes.

 API / surface change plan


Confusing visibility issues with meshes that have skeletons assigned.

Godot version
v4.1.dev.custom_build [18112ba36]
System information
Arch Linux (6.3.2-arch1-1)
Issue description
When a mesh instance is loaded after its assigned Skeleton3D, it displays in editor, but not when running the project. However, if there is another mesh instance that shares the same skin and skeleton of the mesh that fails to display (does not have to share the same mesh) that is loaded before that Skeleton3D, the original mesh instance and that new mesh instance display normally.
But to add more factors, if the project's .godot folder is deleted, two meshes are broken in editor in addition to while running the project, and adding/reparenting a mesh instance to align with the above situation where the meshes display properly does not cause the broken instances to reappear, only when selecting, then deselecting the Skeleton3D node the meshes are assigned to do they return to above behavior. (Sometimes userdata folder for the project must be deleted as well, but I can't figure out what causes this.)
This second situation also seems to occur if two meshes that are children of their assigned Skeleton3D node are both unparented from that Skeleton3D node in the same action.
I feel like #77192 is related given the solution to second situation's problem has the same solution as the mentioned issue.
I apologize for how scatterbrained and difficult to read this issue is, but I really have trouble understanding this bug.
Steps to reproduce
This issue seems quite inconsistent, with some solid pieces, so overall, solid reproduction steps can't be listed, but things to try in the reproduction project -

Play reproduction project on import to observe missing meshes in both editor and while running.
Toggle TestSkeleton2's edit mode, or select and deselect to observe it's child meshes appearing only in editor
Delete generic named MeshInstance3D to observe previously working child mesh instance of TestSkeleton no longer being visible while running project
Unparent both TestCube and TestCube2 from TestSkeleton2 in the same action to observe them both disappearing from editor and while running

Minimal reproduction project
SkeletonAndMeshBugTest.zip (Same as #77192)

Bisected:
4e1d5be9d good
c80a2b4f good
fbb1a929a3 bad
Bad commit:

Merge pull request #74405 from @RandomShaper fix_res_loader
Fix multi-threaded resource loading

NOte that the error:
ERROR: Condition "skeleton->size == 0" is true. Returning: RID()

occurs both in bad revisions and in good revisions.
However, in bad revisions, it is printed every time a scene with skeleton is opened. In the goo revision, this error is only ever printed once, on engine load. I do not understand why.

Probably the same bug as #77222, and #77192 may be another symptom of the same underlying issue?


utmctl help attach fails with an ArgumentParser error

Describe the issue
utmctl help attach fails with an ArgumentParser error. All other help pages do work correctly.
Configuration

UTM Version: 4.1.2
macOS Version: 13.1
Mac Chip (Intel, M1, ...): M1

Crash log
$ utmctl help attach
ArgumentParser/Parsed.swift:59: Fatal error: Trying to get the argument set from a resolved/parsed property.
Trace/BPT trap: 5

@osy it seems to be because of the init() block for Attach. Removing it fixes the crash.


lsp_finder will cause write the file

Describe the bug
If you use lsp_finder and jump to definition or reference, the current buffer will be written.
(look the status line)
https://user-images.githubusercontent.com/39915562/214117102-20bfd93a-3d35-4d63-be6e-8d97fc43167b.mp4
Steps to reproduce

Clone this config: nvim-lua/kickstart.nvim
Install lspsaga with packer
Open any Lua file
Make some changes and do not save it
Move your cursor on a local variable
Enter command: Lspsaga lsp_finder
Go to the definition of this variable
You will see the file has been written

Expected behavior
Go to definition or reference will not cause write file, work like built-in vim.lsp.buf.definition.
Neovim version (nvim -v)
0.8.1
lspsaga commit
749f7fc
Terminal name/version
kitty 0.26.5

lspsaga just handle lsp . there is no vim behavior i did.   can't reproduce. please check your config ?


DateTime with timezone could not be normalised.

Hey guys!
Using:  {:explorer, "~> 0.7.1"}
I was trying to read a Parquet in Livebook. One of my columns has timestamp strings in the following format: 2023-11-20 03:00:00 but when trying to parse it, something is sticking some timezone information as metadata.
Hence, I'm receiving the following error:
** (FunctionClauseError) no function clause matching in Explorer.PolarsBackend.Shared.normalise_dtype/1

    The following arguments were given to Explorer.PolarsBackend.Shared.normalise_dtype/1:

        # 1
        "datetime[ns, UTC]"

    Attempted function clauses (showing 10 out of 15):

        def normalise_dtype("binary")
        def normalise_dtype("bool")
        def normalise_dtype("cat")
        def normalise_dtype("date")
        def normalise_dtype("time")
        def normalise_dtype("datetime[ms]")
        def normalise_dtype("datetime[ns]")
        def normalise_dtype("datetime[μs]")
        def normalise_dtype("duration[ms]")
        def normalise_dtype("duration[ns]")
        ...
        (5 clauses not shown)

    (explorer 0.7.1) lib/explorer/polars_backend/shared.ex:157: Explorer.PolarsBackend.Shared.normalise_dtype/1
    (elixir 1.15.7) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2
    (elixir 1.15.7) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2
    (explorer 0.7.1) lib/explorer/polars_backend/shared.ex:80: Explorer.PolarsBackend.Shared.create_dataframe/1
    (explorer 0.7.1) lib/explorer/polars_backend/lazy_frame.ex:176: Explorer.PolarsBackend.LazyFrame.from_parquet/3
    (explorer 0.7.1) lib/explorer/data_frame.ex:755: Explorer.DataFrame.from_parquet!/2
     my_path/explorer_explorations.livemd#cell:v2ue37r2nqfw7bu4fxuufm3wbfoafrxl:3: (file)

Other columns are simple strings, ints and floats, so only the timestamp one seems to be the source of the problem.
Thanks

Hi @halian-vilela :)
Explorer currently only supports naive datetimes. Can you show the code that produces the error?

That does seem quite by the book.
So I'm not as familiar with parquet files as I'd like to be. I'll weigh in, but I think @philss or @cigrainger will know more.
My initial reading of this issue is that, unfortunately, your parquet file simply has a type that we don't support. The fix would be to alter the file so that column is of a type we do support.
One thing to note is that you can supply a list of columns with the columns option. If there is some exploration you could do that doesn't require the timestamp column, you could probably do columns: all_columns_except_timestamp while you wait for the others to weigh in.

My initial reading of this issue is that, unfortunately, your parquet file simply has a type that we don't support. The fix would be to alter the file so that column is of a type we do support.

I think this is correct! We just don't support datetimes that contains the timezone yet.
An alternative for the :columns option is to use Explorer.DataFrame.discard/2 to drop the unwanted column from the DF.
Since the problem only occurs when we want to inspect the DF, this should work fine.

It is not very complex, we are adding new data types all the time, we just need to get around to adding this one. :) Although we would need a timezone database to convert some of those back to Elixir. But we should at least be able to read them from Polars side.

That's because we don't even have a chance to get to the resulting data-frame after the attempted conversion.

@halian-vilela I thought we could do without passing by the inspection of the resultant DF :/
Did you try something like this (without an intermediate assignment)?
df =
  Kino.FS.file_spec("2023-11-21_file.parquet")
  |> Explorer.DataFrame.from_parquet!(lazy: true)
  |> Explorer.DataFrame.discard("your-column")

And about adding a new type: we could start by supporting datetimes with the UTC timezone only, and then we add the timezone database to convert back to Elixir.

And about adding a new type: we could start by supporting datetimes with the UTC timezone only, and then we add the timezone database to convert back to Elixir.

Great idea!

@billylanchantin we can close this one, right?

@josevalim I think so! https://github.com/elixir-explorer/explorer/pull/903 should have added support for this.
The real proof would be if @halian-vilela is able to parse the original .parquet file using main. But I'd also be ok with closing this issue on faith and letting someone reopen if we didn't get it right :)

Hi @billylanchantin ! Thanks for reaching out! I'll give it a try later today or tomorrow morning and tell you next!


mini.pick: auto jump with one destination

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md

Module(s)
mini.pick
Description
For LSP type pickers, it would be useful to automatically jump to a location when there is only one location to jump to without opening the menu. This could be implemented as a picker option.

Thanks for the suggestion!
This was already discussed during beta-testing. My reasoning is that starting a picker should always result into showing a picker.
Closing as not planned.


avx2: added impl for mm{,256}_maskload_epi{32,64}

avx2: added impl for mm{,256}_maskload_epi{32,64}

I tried everything as suggested and I managed to pass the native aliases tests, only a little change in test_simde_mm{,256}_maskload_epi64 was required


unnecessary vpf check?

There's a check in vpf to make sure the total volume in spheres doesn't exceed the box volume: https://github.com/manodeep/Corrfunc/blob/master/Corrfunc/theory/vpf.py#L207
But I'm not sure that condition is necessary?  Spheres are allowed to overlap in vpf, right?
@manodeep do you know why this is there?

it's a sanity check to make sure that the total number of spheres requested is sensible. If the total volume exceeds the box volume, then there must be some non-independent data-points, and therefore, the total number of spheres used is no longer a fair representation of the amount of scatter expected.  In those cases, it is betterr to use a smaller number of random spheres (which might overlap). Does that make sense?

I guess I was thinking about it like this.  The VPF tells you what the probability is of having 0 (or N) particles in a sphere thrown down at random in a box.  So if we throw down as many such random spheres as possible, isn't the fraction with N exactly what we want to know?
I agree a single box is only going to be a single sampling of the "true" VPF, but I would think limiting the number of spheres just gives you a noisier estimate of the VPF, not a less biased one.
Perhaps the real issue is that one shouldn't trust the large-radius VPF measurements from one box, but maybe one wants to be able to get a low-noise estimate of it, even if it is biased, so one can average over multiple boxes, for example.  And at small scales, maybe it's useful to be able to "oversample" to beat down noise some more when it's at a radius that you do trust the measurement.

I am not sure how repeatedly re-sampling the same volume would give a less noisy estimate of the (large-R) VPF. If anything, the larger number of spheres will make you underestimate the error on the VPF. Of course, the only way to really get the scatter in the VPF is by looking at the scatter in the measurement over many different realisations.
Having said all that, I have never tested the bias-variance - seems like an easy enough test to run and check whether limiting the total volume is meaningful. And I can certainly see an use-case for a keyword parameter that allows the user to over-ride the volume check.

For the large-R VPF, if one is going out to 20% of the box, for example, then that's only 30 spheres.  So the granularity of the VPF is only 3%!  That's a pretty extreme case, but perhaps we should let the user make this choice.  What do you think about changing the error to a warning?  That's slightly less overhead than a new parameter, but I'm also fine with that.

If the user really wants to probe Rmax to 20% of Lbox, then restricting the total number of spheres seems like a good idea!
Though I like the idea of changing to a warning, I have found that people just ignore warnings. It would be a little more work to put in a override_volume_check keyword, but at least that will ensure that users have to consciously make that choice.

Well, even a much more reasonable case, like 5% of the box, is only 2000
spheres, which may not be enough to capture rare small-scale events that
may nonetheless hold interesting information.
If the user wants the vpf across a range of Rmax scales, we might say from
a computational perspective that it makes sense for the user to run vpf
many times, decreasing nspheres as one increases Rmax.  But the structure
of the API doesn't really suggest that, since we are providing nbins to
allow simultaneously measuring across many scales.  So... given that the
vpf is cheap, I am in favor of lifting the restriction on spheres
altogether and making it a warning!  What do you think?
On Tue, Nov 10, 2020 at 5:08 PM Manodeep Sinha<EMAIL_ADDRESS>wrote:

If the user really wants to probe Rmax to 20% of Lbox, then restricting
the total number of spheres seems like a good idea!
Though I like the idea of changing to a warning, I have found that people
just ignore warnings. It would be a little more work to put in a
override_volume_check keyword, but at least that will ensure that users
have to consciously make that choice.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/manodeep/Corrfunc/issues/237#issuecomment-724996707,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABLA7S77LXC5TQCUKYZPVDLSPG2WTANCNFSM4TNEVXUA
.

--
Lehman Garrison<EMAIL_ADDRESS>Flatiron Research Fellow, Cosmology X Data Science Group
Center for Computational Astrophysics, Flatiron Institute
lgarrison.github.io

Are you concerned with the extra code required to over-ride the default behaviour? To me, it seems like adding a boolean keyword override_volume_check or allow_oversampling would not be that much code but would let the user get the desired behaviour. Regardless, I do agree that the behaviour might be desirable - I am trying to avoid making any default choices that can impact the fidelity of the results.
I am not sure how you would capture a rare, small-scale event with the vpf? The measurement (i.e., the mean of nspheres) is unlikely to be affected much, the standard deviation might be - is that the kind of effect you are thinking about?

Yes, it's a combination of not wanting to add more surface area to the API, and a lingering feeling that this check shouldn't be there at all.  The condition forces you to miss a lot of sphere configurations!
By "rare events", I mean low-amplitude counts-in-cells.  I think for any radius (doesn't have to be small), if you go to high enough (or small enough) counts, the probability p(N) will be very low.  And then you probably want at least 10/p(N) spheres to get above Poisson noise.  But the volume condition doesn't know anything about p(N), so in many cases it won't let you use the appropriate number of spheres!

Seems like you feel fairly strongly about this :). Changing to a warning falls under the same scope as checking for the ratio - Rmax/Lbox in the correlation function caiculations - something we do not do currently.
Since the change will alter the default behaviour, should we milestone for a minor release (i.e., 2.4.0) rather than a patch release?

Sorry! I swear I wasn't planning on dying on this hill... I haven't worked with the VPF before, so I'm just trying to think it through and make sure I've wrapped my head around what's going on. And hopefully doing so will help newcomers to the code, especially since I think many students use corrfunc!
So do you think you agree with my assessment? If so, then yes, 2.4.0 sounds good to me.  Do you think we could also do the boxsize change (#199) in that release?

Hehehe - definitely seemed like the hill :). All good - let's milestone this change for 2.4.0. Did you want to PR this up?
Seems like the boxsize PR has some merge conflicts - are you able to fix those? Otherwise, I think that one is good to go but I will take one final look (it's been a while)
I am assuming this means that the next release will be v2.4.0. There are a lot of issues that are milestoned for 2.4.0 - we might have to go through and check what's feasible

Yes, sounds good, I'll take a look tomorrow.

Hi! I'm Lucia, and I'm the one who brought up this issue to Lehman while using CORRFUNC for my current projects. I was throwing CORRFUNC at much smaller volumes that I'm sure you wrote this for, and was struggling with the code stumbling for radii where I knew the VPF could still be trustworthy and measured, and finding it was giving inconsistent results because of the undersampling the check imposed. (So if anyone is dying on this hill, it's me, lol.)
My paper that's in press right now is very relevant here, and Lehman's mentioned some things that I brought up to him from my work: https://arxiv.org/abs/2011.03556. Specifically, Section 3.3 discusses some common-sense limits of when the VPF can be measured given a sample's density and volume, which quantifies the concern of when a radius is too large. Still, regardless of whether the radius you're measuring the VPF for is valid or can give accurate results, one should still oversample with the dropped test spheres to at least guarantee that the act of measuring the VPF isn't adding additional uncertainty.
I'm about to PR a branch with the updated vpf.py that completely omits the check, though I did draft one earlier that gave folks the option to override the check with a flag. CORRFUNC is awesome and I'm happy to contribute a tiny improvement to it!

Hi @laperezNYC - my name is Manodeep - nice to e-meet you! Thank you for using Corrfunc and even more thanks for contributing an improvement.


Cannot disable tracking

Sometimes, the option to disable the tracking does not appear!

The problem happens when there is an invalid entry.

I haven't seen this problem happens anymore.


App crashes when calling from iPhone

The plugin works like a charm on Android, but when trying to make the phone call on iOS it breakes.
The code i use to make the call is this:
window.plugins.CallNumber.callNumber(function(){}, function(){}, number, true);
The app crashes in CFCallNumber.m in this line:
number = [number stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
This is the log i get from xCode:
AccesiveMobileTipo1[1398:1158471] -[__NSCFNumber stringByAddingPercentEscapesUsingEncoding:]: unrecognized selector sent to instance 0x16d00770
2017-03-29 10:15:47.068092 AccesiveMobileTipo1[1398:1158471] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFNumber stringByAddingPercentEscapesUsingEncoding:]: unrecognized selector sent to instance 0x16d00770'
*** First throw call stack:
(0x1b8c0df7 0x1ab23077 0x1b8c6505 0x1b8c4579 0x1b7e93d8 0xab215 0x306d57 0x31353b 0x314d9f 0x314ba7 0x1b11b937 0x1b11b490)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb)

I had the same problem. It was solved by passing the phone number as string in JavaScript.

Hello, i tried doing this num.toString() but i didn't get it to work. If you could please tell me how you did it i would really appreciate it.

Hello, I am using it like this:
this.callNumber.callNumber(telefone, true)

Hello, I have been facing this problem too. I am using numbers as strings but with the same problem. The application crashes after the call.

I was facing the same issue, in my case, I was using Ionic 4 and I was passing the number from my html component to my ts file as a number, to solve it I had to cast it from number to string, the application doesn't crash after the call (iOS 12.3).


Update Devfile API Education Module with more information

Which area/kind this issue is related to?

/area api
Issue Description

This Devfile API Education module documentation would need to be updated with more information. This is seen as a collaborative team effort since not a single person might have all the information about the API since it's inception..

Closing this issue, as it is marked as done.


Error in playerObject

Sometimes when a player join the room who you're not the host, a error occur in playerObjectCreated event. This cause a loop and create more than one playerObject for one player.

It's not a bug, but a feature. This callback will run for each player object just once. If you just joined the room, there are more than one player inside. It runs once for each one of them. Note that onPlayerJoin does not work like this, that's why I created this callback so that we can now define custom variables inside all player objects by just writing it here once. Of course it's not as simple as that, but you get the idea.


chore: update CI to test against node v20

No change to logic. This updates GitHub actions CI to test on node v19 and v20.

Codecov Report
Patch coverage has no change and project coverage change: -1.19 :warning:

Comparison is base (a3a7e74) 97.19% compared to head (c10b4dd) 96.01%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1123      +/-   ##
==========================================
- Coverage   97.19%   96.01%   -1.19%
==========================================
  Files          36       36
  Lines        1354     1354
==========================================
- Hits         1316     1300      -16
- Misses         38       54      +16

see 6 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


React readme

Try re-forking the repository and make correction on the commits.
Star();
getStdId();

an example of correct commit is:
[React][Author] state description with example added


WIP: fix: wip enable editor hover properly to show hovers without glitches

May be Closes #182213

Note: you'll want to rebase/merge with the main branch now that #181936 has been merged, since it also touches this logic.

This doesn't really solve the problem for me

This doesn't really solve the problem for me

What exactly isn't working , I tested error scenarios, debug expressions and non debug expressions. Its looks good on my side. No overlaps and no problems I find with mouse move
If you let me know your reproducible behaviour , I can check that otherwise I don't have an idea where exactly to debug. Thanks
https://github.com/microsoft/vscode/assets/8697234/4b4b17fa-0137-45a8-8041-a5eac134f5eb

Oh, it does work when I go to mouse over the hover, so that has improved. But if I move left/right, the hover hides again, that's what I was hitting.


Implement Dynamic Bucket Rate Limits

Description
Fixes #301
Relevant docs: https://discord.com/developers/docs/topics/rate-limits#rate-limits
Bucket Rate Limit
Bucket rate limits should be fully functioning.
Global Rate Limit
A simple global rate limit should be functioning. As the real global rate limit is variable per discord account, the current logic simply obeys 423 retry instructions, it does not track the 50 requests/second default rate limit . A "token global rate limit config" could be implemented at a later date.
Implements HttpRoute as loosely defined in docs.
Rewrites HttpBucket as defined in docs.
Rewrites HttpHandler to manage HttpBuckets and the resulting retry logic.
In HttpRequest, replaces String path with HttpRoute route.
In HttpEndpoints, replaces ~100 String path args with HttpRoute route args.
Connected issues & other potential problems
Any package that calls HttpEndpoints.sendRawRequest()  needs to migrate to using HttpEndpoints.sendCustomRequest()  for requests to participate in bucket rate limits. Otherwise client side pre-emptive rate limiting may fail for any given request.
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[ ] Ran dart analyze or make analyze and fixed all issues
[x] Ran dart format --set-exit-if-changed -l 160 ./lib or make format and fixed all issues
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked my changes haven't lowered code coverage

@NDSo whats the state of this PR? Are you able to finish it?


Disable user cache automatically for JWT and PKI authentication

ITT-1238

maybe this solution is better https://github.com/floragunncom/search-guard/pull/501

I agree, let's go with #501